Hogyan küldesz promóciós kódokat 1M felhasználónak rövid időablakban?

Question

IT Interview Practice · Accepted Answer

Soha ne iterálj végig 1M felhasználón egy request handlerben — **oszd szét a munkát egy queue-n keresztül**, throttle-özz arra a szintre, amit az egyes szolgáltatók el tudnak fogadni, tegyél minden küldést **idempotenssé**, és a hibákat irányítsd egy DLQ-ba újrapróbálásra. Az API-hívás csak sorba állít; a lassú I/O-t a workerek végzik.

## Architektúra

```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
```

## Komponensek és folyamat

- **Campaign API** kiírja a kampányt és sorba állítja a jobokat — egyet felhasználónként vagy **~500-as batchenként**, hogy csökkentse a queue overheadet. Azonnal visszatér; az 1M küldés a queue mögött történik.
- **Queue (Kafka / SQS)** a puffer és a *replay* log. Ha a workerek összeomlanak, az üzenetek a helyükön maradnak; semmi kód nem vész el. Partícionálj `user_id` szerint, hogy a felhasználónkénti sorrend stabil legyen.
- **Worker pool** kiveszi a jobokat és a queue lag alapján autoscale-öl. Minden worker: (1) lefoglal egy egyedi promóciós kódot, (2) ellenőriz egy **dedup kulcsot** `SETNX sent:{campaign}:{user}` a Redisben, hogy egy újraküldött üzenet soha ne küldjön duplán, (3) áthalad egy **rate limiteren**, amely a szolgáltató kvótájához van méretezve, (4) meghívja az Email/SMS/Push szolgáltatást.
- **Rate limiter** a lényeg: a SendGrid vagy a Twilio throttle-öl vagy feketelistára tesz a limitük felett. Egy szolgáltatónkénti Redis token bucket megsapkázza a kimenő RPS-t, függetlenül attól, hány worker fut.
- **DLQ** elkapja a mérgező üzeneteket N újrapróbálás után exponenciális backoff + jitter mellett, így egy rossz cím soha nem blokkolja a kampányt.

## Interjú szemszög

Az interjúztató azt vizsgálja, érted-e a **szétcsatolást (decoupling) és a back-pressure-t**. Egy "kiváló" válasz megnevezi a pontos hibát: idempotencia nélkül egy at-least-once queue plusz egy retry azt jelenti, hogy a felhasználók három kódot kapnak; rate limiter nélkül önmagadat DDoS-olod a szolgáltatónál, és nullára throttle-öznek. A gyakori csapda a fan-out szinkron elvégzése ("csak `Promise.all`") — ez leköti a connectionöket, nincs retry, és egy deploynál mindent elveszít.

## Kompromisszumok és hibák

- **At-least-once vs exactly-once**: a queue-k olcsón adnak at-least-once-ot; a "gyakorlatilag egyszer"-t a Redis dedup kulccsal veszed meg, nem egy drága exactly-once brokerrel.
- **Throughput vs szolgáltatói limitek**: örökké hozzáadhatsz workereket, de a szolgáltatói kvóta a valódi plafon — kérj kvótanövelést vagy melegíts elő a kampány előtt.
- **Hiba**: Redis leáll → a küldések elakadnak (fail closed, ne hagyd ki a dedupot és kockáztasd a duplikációt). Vezess kampányonkénti számlálót, hogy egy incidens után folytatni tudj, ne újraindítani.

Architektúra

Komponensek és folyamat

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések