Jak zaprojektowałbyś ogólnofirmowy serwis powiadomień?

Question

IT Interview Practice · Accepted Answer

Zbuduj jeden serwis, który każdy zespół wywołuje z **typem powiadomienia + odbiorcą**, i pozwól serwisowi rozstrzygnąć kanał, szablon, preferencje użytkownika i priorytet. Kluczowym posunięciem projektowym są **pasy priorytetów (priority lanes)** — OTP nie może czekać za marketingowym mailingiem do 2 mln użytkowników.

## Architektura

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

## Komponenty i przepływ

- **Notify API** przyjmuje typowane żądanie: `{type: "otp", user, data}`. Wywołujący nigdy nie wybierają kanału ani nie piszą treści — to należy do serwisu, więc zmiana szablonu wdraża się raz.
- **Typ → polityka**: każdy **typ** mapuje się na politykę. *OTP* ma wysoki priorytet, SMS+Push, ignoruje rezygnację z marketingu, wygasa po 60 s. *Transakcyjne* (potwierdzenie, reset hasła) ma wysoki priorytet, respektuje preferencje kanałów. *Marketing* ma niski priorytet, bulk lane, ściśle honoruje rezygnację i godziny ciszy.
- **Pasy priorytetów** to osobne topiki Kafka z osobnymi grupami konsumentów. Wysoki pas pozostaje niemal pusty i opróżnia się w milisekundy; bulk lane może być zapchany przez minuty bez wpływu na latency OTP. To pojedyncza najważniejsza decyzja.
- **Serwis preferencji** jest sprawdzany per odbiorca: zrezygnował? godziny ciszy? przełącznik per kanał? limit częstotliwości? Marketing naruszający preferencję jest tu odrzucany.
- **Silnik szablonów** renderuje zlokalizowaną treść z wersjonowanego szablonu + zmiennych, dzięki czemu treść i kod są odseparowane.
- **Adaptery kanałów** opakowują FCM/APNs, SendGrid, Twilio za jednym interfejsem, każdy z własnym rate limiterem, ponowieniami i DLQ (ta sama dyscyplina fan-out co u każdego wysyłacza masowego).

## Perspektywa rozmowy kwalifikacyjnej

Rozmówcy sondują, czy separujesz **odpowiedzialności (concerns)**: wielu kandydatów buduje monolit, który wysyła maile bezpośrednio, a potem odkrywa, że zalewy marketingowe opóźniają OTP. Nazwanie *pasów priorytetów*, *egzekwowania preferencji* i *kluczy idempotentności* (aby ponowione żądanie nie powiadomiło dwukrotnie) to sygnał seniorski. Dobra odpowiedź dodaje kanały; świetna wyjaśnia, dlaczego OTP i marketing nigdy nie mogą dzielić kolejki oraz jak działa **łańcuch fallbacku** (Push zawiódł → SMS).

## Kompromisy i awarie

- **Jeden serwis vs per zespół**: centralizacja daje spójne preferencje, throttling i audyt, ale staje się krytyczną zależnością — musi być HA, bo inaczej awaria OTP przy logowaniu zablokuje całą firmę.
- **Czas rzeczywisty vs koszt**: SMS jest drogi i wolny; preferuj Push/In-App, a do SMS wracaj tylko dla typów o wysokiej wartości.
- **Awaria**: przerwa u dostawcy uruchamia łańcuch fallbacku, a nie twardą porażkę. **Klucze dedupikacji** zapobiegają dwukrotnej wysyłce OTP przy ponownym dostarczeniu z kolejki. Śledź SLO dostarczenia per typ — opóźniony mail marketingowy jest OK, opóźniony OTP to incydent.

Architektura

Komponenty i przepływ

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania