Kısa bir zaman aralığında 1 milyon kullanıcıya promosyon kodlarını nasıl gönderirsiniz?

Question

IT Interview Practice · Accepted Answer

Bir request handler içinde asla 1 milyon kullanıcı üzerinde döngü kurmayın — bunun yerine **bir kuyruk üzerinden fan-out yapın**, her sağlayıcının kabul edebileceği kadarıyla throttle uygulayın, her gönderimi **idempotent** hale getirin ve başarısızlıkları yeniden deneme için bir DLQ'ya yönlendirin. API çağrısı yalnızca kuyruğa iş ekler; yavaş I/O işini worker'lar yapar.

## Mimari

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## Bileşenler ve akış

- **Campaign API** kampanyayı yazar ve işleri kuyruğa ekler — kuyruk yükünü azaltmak için kullanıcı başına bir veya **~500'lük batch** başına bir iş olacak şekilde. Anında geri döner; 1 milyon gönderim kuyruğun arkasında gerçekleşir.
- **Kuyruk (Kafka / SQS)** hem buffer hem de *replay* log'udur. Worker'lar çökerse, mesajlar yerinde kalır; hiçbir kod kaybolmaz. Kullanıcı başına sıralamanın kararlı kalması için `user_id` üzerinden partition yapın.
- **Worker pool** işleri çeker ve queue lag'e göre autoscale olur. Her worker: (1) benzersiz bir promosyon kodu rezerve eder, (2) Redis'te `SETNX sent:{campaign}:{user}` **dedup key** kontrolü yapar, böylece yeniden teslim edilen bir mesaj asla çift gönderim yapmaz, (3) sağlayıcının kotasına göre boyutlandırılmış bir **rate limiter**'dan geçer, (4) Email/SMS/Push çağrısı yapar.
- **Rate limiter** işin can alıcı noktasıdır: SendGrid veya Twilio, limitlerinin üzerinde sizi throttle eder veya kara listeye alır. Her sağlayıcı için bir Redis token bucket, kaç worker çalışırsa çalışsın giden RPS'i sınırlar.
- **DLQ**, üstel backoff + jitter ile N yeniden denemeden sonra poison mesajları yakalar, böylece hatalı bir adres asla kampanyayı bloke etmez.

## Mülakat perspektifi

Mülakatı yapan kişi, **decoupling ve back-pressure** kavramlarını anlayıp anlamadığınızı yokluyor. "Harika" bir cevap tam olarak hangi hatanın oluşacağını adlandırır: idempotency olmadan, at-least-once bir kuyruk artı bir yeniden deneme, kullanıcıların üç kod almasına eşittir; rate limiter olmadan, sağlayıcıya kendi kendinize DDoS yapıp sıfıra kadar throttle edilirsiniz. Yaygın tuzak, fan-out'u senkron yapmaktır ("sadece `Promise.all`") — bu bağlantıları meşgul eder, yeniden deneme yoktur ve bir deploy'da her şeyi kaybeder.

## Ödünleşimler ve hata

- **At-least-once vs exactly-once**: kuyruklar at-least-once'ı ucuza sağlar; "effectively once"ı pahalı bir exactly-once broker ile değil, Redis dedup key ile satın alırsınız.
- **Throughput vs sağlayıcı limitleri**: sonsuza kadar worker ekleyebilirsiniz, ancak gerçek tavan sağlayıcının kotasıdır — kampanyadan önce kota artışı isteyin veya önceden ısındırın.
- **Hata**: Redis çökerse → gönderimler durur (fail closed davranın, dedup'ı atlayıp çift gönderim riskine girmeyin). Bir olaydan sonra yeniden başlatmak değil, devam edebilmek için kampanya başına bir sayaç izleyin.

Mimari

Bileşenler ve akış

Mülakat perspektifi

Ödünleşimler ve hata

İlgili sorular