Miten suunnittelisit koko yrityksen laajuisen ilmoituspalvelun?

Question

IT Interview Practice · Accepted Answer

Rakenna yksi palvelu, jota jokainen tiimi kutsuu antaen **ilmoitustyypin + vastaanottajan**, ja anna palvelun ratkaista kanava, template, käyttäjän asetukset ja prioriteetti. Keskeinen suunnitteluratkaisu on **prioriteettikaistat (priority lanes)** — OTP ei voi odottaa 2M käyttäjän markkinointilähetyksen takana.

## Arkkitehtuuri

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## Komponentit ja tietovirta

- **Notify API** ottaa vastaan tyypitetyn pyynnön: `{type: "otp", user, data}`. Kutsujat eivät koskaan valitse kanavaa tai kirjoita tekstiä — palvelu omistaa sen, joten template-muutos julkaistaan kerran.
- **Tyyppi → policy**: jokainen **tyyppi** kytkeytyy policyyn. *OTP* on korkean prioriteetin, SMS+Push, ohittaa markkinointikiellon, vanhenee 60 s. *Transaktionaalinen* (kuitti, salasanan nollaus) on korkea, kunnioittaa kanava-asetuksia. *Markkinointi* on matala, bulk-kaista, noudattaa tiukasti opt-outia ja hiljaisia tunteja (quiet hours).
- **Prioriteettikaistat** ovat erillisiä Kafka-topiceja erillisillä consumer groupeilla. Korkea kaista pysyy lähes tyhjänä ja tyhjenee millisekunneissa; bulk-kaista voi ruuhkautua minuuteiksi koskematta OTP-latenssiin. Tämä on ainoa tärkein päätös.
- **Preference-palvelu** tarkistetaan per vastaanottaja: opt-out? hiljaiset tunnit? per-kanava-kytkin? frequency cap? Markkinointi, joka rikkoo asetusta, pudotetaan tässä.
- **Template-moottori** renderöi lokalisoidun sisällön versioidusta templatesta + muuttujista, joten teksti ja koodi ovat irrallaan toisistaan.
- **Kanava-adapterit** kääräisevät FCM/APNs, SendGrid, Twilio yhden rajapinnan taakse, kukin omalla rate limiterillään, uudelleenyrityksellään ja DLQ:llaan (sama hajautuskuri kuin millä tahansa bulk-lähettäjällä).

## Haastattelunäkökulma

Haastattelijat tutkivat, erotatko **vastuualueet (concerns)**: monet kandidaatit rakentavat monoliitin, joka lähettää sähköpostin suoraan, ja huomaavat sitten markkinointitulvien viivästyttävän OTP:eja. *Prioriteettikaistojen*, *asetusten valvonnan* ja *idempotenssiavainten* (jottei uudelleen yritetty pyyntö ilmoita kahdesti) nimeäminen on senior-signaali. Hyvä lisää kanavia; loistava selittää, miksi OTP ja markkinointi eivät saa koskaan jakaa jonoa ja miten **fallback-ketju** (Push epäonnistuu → SMS) toimii.

## Kompromissit ja virhetilanteet

- **Yksi palvelu vs per-tiimi**: keskittäminen antaa yhtenäiset asetukset, throttlauksen ja auditoinnin, mutta siitä tulee kriittinen riippuvuus — sen on oltava HA, tai kirjautumis-OTP:n häiriö estää koko yrityksen.
- **Reaaliaikaisuus vs kustannus**: SMS on kallis ja hidas; suosi Push/In-App ja käytä SMS:ää vain korkean arvon tyypeille.
- **Vikatilanne**: palveluntarjoajan häiriö laukaisee fallback-ketjun, ei kovaa virhettä. **Dedup-avaimet** estävät jonon uudelleentoimitusta lähettämästä OTP:tä kahdesti. Seuraa per-tyyppi-toimitus-SLO:ja — viivästynyt markkinointisähköposti on ok, viivästynyt OTP on incidentti.

Arkkitehtuuri

Komponentit ja tietovirta

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset