Miten lähetät promokoodit 1M käyttäjälle lyhyessä aikaikkunassa?

Question

IT Interview Practice · Accepted Answer

Älä koskaan käy 1M käyttäjää läpi silmukassa pyyntökäsittelijässä — **hajauta työ jonon (queue) kautta**, rajoita lähetystahti siihen, mitä kukin palveluntarjoaja pystyy vastaanottamaan, tee jokaisesta lähetyksestä **idempotentti** ja ohjaa epäonnistumiset DLQ:hun uudelleenyritystä varten. API-kutsu vain lisää työn jonoon; workerit tekevät hitaan I/O:n.

## Arkkitehtuuri

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

## Komponentit ja tietovirta

- **Campaign API** kirjoittaa kampanjan ja lisää työt jonoon — yksi per käyttäjä tai per **~500 alkion erä (batch)** vähentääkseen jonon overheadia. Se palauttaa vastauksen välittömästi; ne 1M lähetystä tapahtuvat jonon takana.
- **Jono (Kafka / SQS)** on puskuri ja *replay*-loki. Jos workerit kaatuvat, viestit pysyvät paikoillaan; mitään koodia ei menetetä. Partitioi `user_id`:n mukaan, jotta järjestys per käyttäjä pysyy vakaana.
- **Worker pool** noutaa työt ja skaalautuu automaattisesti jonon viiveen (lag) perusteella. Jokainen worker: (1) varaa uniikin promokoodin, (2) tarkistaa **dedup-avaimen** `SETNX sent:{campaign}:{user}` Redisistä, jotta uudelleentoimitettu viesti ei koskaan aiheuta kaksoislähetystä, (3) kulkee **rate limiterin** läpi, joka on mitoitettu palveluntarjoajan kiintiöön, (4) kutsuu Email/SMS/Push.
- **Rate limiter** on ydinasia: SendGrid tai Twilio throttlaa tai mustalistaa sinut, jos ylität heidän rajansa. Redis-token bucket per palveluntarjoaja rajaa lähtevän RPS:n riippumatta siitä, montako workeria on käynnissä.
- **DLQ** ottaa kiinni myrkylliset viestit N uudelleenyrityksen jälkeen käyttäen eksponentiaalista backoffia + jitteriä, jottei virheellinen osoite koskaan pysäytä koko kampanjaa.

## Haastattelunäkökulma

Haastattelija tutkii, ymmärrätkö **irtikytkennän (decoupling) ja back-pressuren**. "Loistava" vastaus nimeää täsmällisen vikatilanteen: ilman idempotenssia at-least-once-jono plus uudelleenyritys tarkoittaa, että käyttäjät saavat kolme koodia; ilman rate limiteriä teet itse DDoS-hyökkäyksen palveluntarjoajaan ja sinut throttlataan nollaan. Yleinen ansa on tehdä hajautus synkronisesti ("just `Promise.all`") — se sitoo yhteydet, siinä ei ole uudelleenyritystä, ja se menettää kaiken deployn yhteydessä.

## Kompromissit ja virhetilanteet

- **At-least-once vs exactly-once**: jonot antavat at-least-oncen halvalla; ostat "efektiivisesti kerran" -takeen Redis-dedup-avaimella, et kalliilla exactly-once-brokerilla.
- **Throughput vs palveluntarjoajan rajat**: voit lisätä workereita loputtomasti, mutta palveluntarjoajan kiintiö on todellinen katto — pyydä kiintiön korotusta tai lämmittele ennen kampanjaa.
- **Vikatilanne**: Redis alhaalla → lähetykset pysähtyvät (fail closed, älä ohita dedupia ja riskeeraa kaksoislähetyksiä). Pidä per-kampanja-laskuria, jotta voit jatkaa etkä käynnistää uudelleen häiriön jälkeen.

Arkkitehtuuri

Komponentit ja tietovirta

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset