Como você projetaria um serviço de notificações para toda a empresa?

Question

IT Interview Practice · Accepted Answer

Construa um único serviço que toda equipe chama com um **tipo de notificação + destinatário**, e deixe o serviço resolver canal, template, preferências do usuário e prioridade. A jogada chave do design são as **faixas de prioridade (priority lanes)** — um OTP não pode esperar atrás de um disparo de marketing para 2M de usuários.

## Arquitetura

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

## Componentes e fluxo

- **Notify API** recebe uma requisição tipada: `{type: "otp", user, data}`. Os chamadores nunca escolhem um canal nem escrevem o texto — o serviço é o dono disso, então uma mudança de template é publicada uma única vez.
- **Tipo → política**: cada **tipo** mapeia para uma política. *OTP* é de alta prioridade, SMS+Push, ignora opt-out de marketing, expira em 60s. *Transacional* (recibo, reset de senha) é alta, respeita preferências de canal. *Marketing* é baixa, faixa de bulk, honra estritamente opt-out e horas de silêncio.
- **Faixas de prioridade** são tópicos Kafka separados com grupos de consumidores separados. A faixa alta permanece quase vazia e é drenada em milissegundos; a faixa de bulk pode acumular por minutos sem afetar a latência do OTP. Esta é a decisão mais importante de todas.
- **Serviço de preferências** é verificado por destinatário: fez opt-out? horas de silêncio? toggle por canal? limite de frequência? Marketing que viola uma preferência é descartado aqui.
- **Engine de templates** renderiza conteúdo localizado a partir de um template versionado + variáveis, para que texto e código fiquem desacoplados.
- **Adaptadores de canal** envolvem FCM/APNs, SendGrid, Twilio por trás de uma única interface, cada um com seu próprio rate limiter, retry e DLQ (a mesma disciplina de fan-out de qualquer remetente em massa).

## Perspectiva de entrevista

Entrevistadores sondam se você separa **preocupações (concerns)**: muitos candidatos constroem um monólito que envia email diretamente, e depois descobrem que enxurradas de marketing atrasam os OTPs. Nomear *faixas de prioridade*, *aplicação de preferências* e *chaves de idempotência* (para que uma requisição reprocessada não notifique em duplicidade) é o sinal de senioridade. Bom adiciona canais; excelente explica por que OTP e marketing nunca podem compartilhar uma fila e como funciona uma **cadeia de fallback** (Push falha → SMS).

## Trade-offs e falhas

- **Um serviço vs por equipe**: centralizar dá preferências, throttling e auditoria consistentes, mas se torna uma dependência crítica — precisa ser HA, ou uma indisponibilidade de OTP de login bloqueia a empresa inteira.
- **Tempo real vs custo**: SMS é caro e lento; prefira Push/In-App e recorra a SMS apenas para tipos de alto valor.
- **Falha**: a indisponibilidade de um provedor dispara a cadeia de fallback, não uma falha total. **Chaves de dedup** impedem que uma reentrega da fila envie um OTP duas vezes. Rastreie SLOs de entrega por tipo — um email de marketing atrasado tudo bem, um OTP atrasado é um incidente.

Arquitetura

Componentes e fluxo

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas