Recepción de siniestros por múltiples canales

Contexto

Una aseguradora necesitaba que sus clientes pudieran reportar un siniestro desde donde estuvieran: la app móvil, un bot de WhatsApp, y más canales por venir.

Problema

El reporte y su procesamiento estaban acoplados: si el sistema que evalúa y despacha el caso se caía o se saturaba, el cliente simplemente no podía reportar. En un siniestro, ese momento es el peor posible para fallar. Además, cada canal nuevo implicaba tocar el núcleo del sistema.

Decisiones

• Separar recepción de procesamiento con arquitectura orientada a eventos sobre Kafka. El canal solo publica; el reporte queda registrado aunque el resto del sistema esté degradado.
• Consumidores idempotentes, con reintentos y colas de mensajes fallidos, para que un reintento no genere dos siniestros duplicados.
• Una capa de integración por canal con autenticación distinta según el origen: JWT con validación JWKS para la app de clientes, API keys resguardadas en un gestor de secretos para el bot.
• Documentar los límites entre servicios con modelo C4 antes de escribir código, y separar lectura de escritura con CQRS donde el volumen lo justificaba.
• Despliegue en Kubernetes con manifiestos por ambiente, para que dev, sit, uat y producción no se pisen.

Resultado

El canal de recepción dejó de depender de la disponibilidad del procesamiento: si algo falla aguas abajo, el cliente igual completa su reporte y el evento se procesa cuando el sistema se recupera. Agregar un canal nuevo hoy significa escribir su capa de integración, no modificar el núcleo: el bot de WhatsApp y la app de clientes entraron por la misma puerta con esquemas de autenticación distintos. Y con los ambientes separados por manifiestos, una liberación a producción dejó de ser un evento de riesgo coordinado a mano.

Lo que aprendí

Que la parte difícil de una arquitectura orientada a eventos no es publicar el evento: es todo lo que pasa cuando llega dos veces, llega tarde, o no llega.