Kaip išsiųstumėte reklaminius kodus 1 mln. naudotojų per trumpą laiko tarpą?

Question

IT Interview Practice · Accepted Answer

Niekada neapdorokite 1 mln. naudotojų cikle užklausos apdorojimo funkcijoje — **paskirstykite darbą per eilę**, ribokite srautą pagal tai, ką kiekvienas tiekėjas gali priimti, padarykite kiekvieną siuntimą **idempotentišką** ir nukreipkite klaidas į DLQ pakartotiniam bandymui. API iškvietimas tik įdeda užduotį į eilę; visą lėtą I/O atlieka workeriai.

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

## Komponentai ir eiga

- **Campaign API** įrašo kampaniją ir įdeda užduotis į eilę — po vieną kiekvienam naudotojui arba **partijomis po ~500**, kad sumažintų eilės apkrovą. Ji grąžina atsakymą akimirksniu; 1 mln. siuntimų vyksta už eilės.
- **Eilė (Kafka / SQS)** yra buferis ir *pakartojimo* žurnalas. Jei workeriai nulūžta, žinutės lieka vietoje; joks kodas neprarandamas. Skaidykite pagal `user_id`, kad eiliškumas kiekvienam naudotojui būtų stabilus.
- **Worker pool** ima užduotis ir automatiškai keičia mastą pagal eilės vėlavimą (queue lag). Kiekvienas workeris: (1) rezervuoja unikalų reklaminį kodą, (2) tikrina **dedup raktą** `SETNX sent:{campaign}:{user}` Redis, kad pakartotinai pristatyta žinutė niekada nesiųstų dukart, (3) praeina per **rate limiter**, pritaikytą tiekėjo kvotai, (4) iškviečia Email/SMS/Push.
- **Rate limiter** yra esmė: SendGrid ar Twilio pradės riboti arba įtrauks jus į juodąjį sąrašą viršijus jų limitą. Redis token bucket kiekvienam tiekėjui riboja išeinančių užklausų RPS nepriklausomai nuo to, kiek workerių dirba.
- **DLQ** perima problemines žinutes po N pakartojimų su eksponentiniu backoff + jitter, kad blogas adresas niekada neužblokuotų kampanijos.

## Interviu perspektyva

Interviuotojas tikrina, ar suprantate **atsiejimą (decoupling) ir back-pressure**. „Puikus" atsakymas įvardija konkretų gedimą: be idempotentiškumo at-least-once eilė plius pakartojimas reiškia, kad naudotojai gaus tris kodus; be rate limiter jūs patys sau surengiate DDoS tiekėjui ir jus apribos iki nulio. Dažna spąstų forma — atlikti darbo paskirstymą sinchroniškai („tiesiog `Promise.all`") — tai užima ryšius, neturi pakartojimo ir viską praranda per deployment.

## Kompromisai ir gedimai

- **At-least-once vs exactly-once**: eilės pigiai suteikia at-least-once; „faktiškai vieną kartą" pasiekiate Redis dedup raktu, o ne brangiu exactly-once brokeriu.
- **Throughput vs tiekėjo limitai**: workerių galite pridėti be galo, bet tiekėjo kvota yra tikroji lubos — prašykite kvotos padidinimo arba iš anksto pašildykite prieš kampaniją.
- **Gedimas**: Redis nulūžta → siuntimai sustoja (fail closed, nepraleiskite dedup ir nerizikuokite dublikatais). Sekite kiekvienos kampanijos skaitiklį, kad galėtumėte tęsti, o ne pradėti iš naujo po incidento.

Architektūra

Komponentai ir eiga

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai