¿Cómo diseñarías un servicio de notificaciones para toda la empresa?

Question

IT Interview Practice · Accepted Answer

Construye un único servicio al que cada equipo llame con un **tipo de notificación + destinatario**, y deja que el servicio resuelva el canal, la plantilla, las preferencias del usuario y la prioridad. La decisión de diseño clave son los **carriles de prioridad (priority lanes)** — un OTP no puede esperar detrás de un envío masivo de marketing a 2M de usuarios.

## Arquitectura

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

- **Notify API** recibe una request tipada: `{type: "otp", user, data}`. Quien llama nunca elige canal ni escribe el copy — el servicio es dueño de eso, así que un cambio de plantilla se despliega una sola vez.
- **Tipo → política**: cada **tipo** se mapea a una política. *OTP* es de alta prioridad, SMS+Push, ignora el opt-out de marketing, expira en 60s. *Transaccional* (recibo, reset de contraseña) es alta, respeta las preferencias de canal. *Marketing* es baja, carril bulk, honra estrictamente el opt-out y las quiet hours.
- **Los priority lanes** son topics de Kafka separados con consumer groups separados. El carril alto se mantiene casi vacío y se drena en milisegundos; el carril bulk puede acumularse durante minutos sin tocar la latencia del OTP. Esta es la decisión individual más importante.
- **El servicio de preferencias** se consulta por destinatario: ¿opted out? ¿quiet hours? ¿toggle por canal? ¿frequency cap? El marketing que viole una preferencia se descarta aquí.
- **El motor de plantillas** renderiza contenido localizado a partir de una plantilla versionada + variables, de modo que el copy y el código quedan desacoplados.
- **Los adaptadores de canal** envuelven FCM/APNs, SendGrid, Twilio detrás de una única interfaz, cada uno con su propio rate limiter, reintento y DLQ (la misma disciplina de fan-out que cualquier emisor masivo).

## Perspectiva de la entrevista

Los entrevistadores sondean si separas las **responsabilidades**: muchos candidatos construyen un monolito que envía email directamente, y luego descubren que las avalanchas de marketing retrasan los OTP. Nombrar los *priority lanes*, la *aplicación de preferencias* y las *idempotency keys* (para que una request reintentada no notifique dos veces) es la señal de senior. Bueno añade canales; excelente explica por qué OTP y marketing nunca deben compartir cola y cómo funciona una **cadena de fallback** (falla Push → SMS).

## Compensaciones y fallos

- **Un servicio vs uno por equipo**: centralizar da preferencias, throttling y auditoría consistentes, pero se convierte en una dependencia crítica — debe ser HA, o una caída del OTP de login bloquea a toda la empresa.
- **Tiempo real vs coste**: el SMS es caro y lento; prefiere Push/In-App y recurre al SMS solo para tipos de alto valor.
- **Fallo**: la caída de un proveedor dispara la cadena de fallback, no un fallo duro. Las **dedup keys** evitan que una reentrega de la cola envíe un OTP dos veces. Monitorea los SLO de entrega por tipo — un email de marketing retrasado está bien, un OTP retrasado es un incidente.

Arquitectura

Componentes y flujo

Perspectiva de la entrevista

Compensaciones y fallos

Preguntas relacionadas