Kafka en Sistemas de Seguros: Arquitectura para Alta Concurrencia

Cuando una aseguradora necesita procesar un alto volumen de transacciones diarias — enrolamientos, pagos domiciliados, validaciones contra listas de riesgo, tokenización de tarjetas — el modelo request-response síncrono se vuelve frágil cuando una operación crítica depende de varias integraciones con latencias distintas; bajo picos, ese acoplamiento amplifica tiempos de espera si no hay límites y degradación controlada.

El problema real: acoplamiento temporal

En un sistema síncrono tradicional, el tiempo que tarda el servicio de tokenización de tarjetas se suma al tiempo de respuesta total de la transacción. Si la validación contra listas internas de riesgo, listas de personas bloqueadas y fuentes de sanciones —cada una con su frecuencia de actualización, versión consultada y evidencia— está bajo carga, toda la cadena espera. El resultado es predecible: timeouts, reintentos manuales y errores de conciliación.

Apache Kafka resuelve esto con un modelo fundamentalmente diferente: en lugar de que los servicios se llamen entre sí, publican eventos en topics y cada consumidor los procesa de forma independiente, a su propio ritmo. Kafka puede ofrecer procesamiento exactly-once dentro de flujos Kafka bien configurados; cuando intervienen APIs, procesadores de pago o bases de datos externas siguen haciendo falta identificadores idempotentes, manejo de duplicados y conciliación (por ejemplo, con el patrón outbox).

Cómo se resuelve el enrolamiento con eventos

El patrón habitual en plataformas aseguradoras es el siguiente: el inicio del enrolamiento se publica como evento, y las validaciones —identidad, listas restrictivas, tokenización del medio de pago— se procesan como consumidores independientes que publican su resultado. La coordinación sigue el patrón saga, por coreografía (cada servicio reacciona a los eventos de los demás) o por orquestación (un componente reúne los resultados y decide si el enrolamiento procede). El valor no está en la mensajería, está en que las validaciones no se bloqueen entre sí.

El alta se modela como una máquina de estados —pendiente, validando, aprobado, rechazado, vencido, en revisión— y se define qué pasa ante resultados duplicados o tardíos, indisponibilidad de un tercero y vencimientos.

La diferencia operativa es de naturaleza, no de grado. Un pico de demanda deja de convertirse de inmediato en timeouts: la cola absorbe el volumen y cada consumidor procesa a su ritmo. Se paga con latencia de procesamiento. El desacoplamiento reduce la propagación de fallas, pero no elimina el riesgo: hacen falta límites de consumo, reintentos acotados, colas de excepción y monitoreo del atraso.

Trazabilidad como ciudadano de primera clase

Uno de los requerimientos más estrictos en el sector asegurador es la auditoría. Cada transacción — desde la solicitud inicial hasta la confirmación del pago — debe ser rastreable con timestamps, estados intermedios e identidad del sistema que procesó cada paso. Los eventos son una fuente valiosa de evidencia, pero no sustituyen una bitácora de auditoría: hay que definir eventos auditables, correlación, sello de tiempo, integridad, retención y un repositorio consultable separado de la retención de Kafka.

Los topics no deben distribuir datos sensibles: se publican referencias o identificadores seudonimizados y el mínimo dato necesario; cifrado en tránsito y reposo, acceso por topic y retención definida. Los datos de tarjeta quedan fuera de la plataforma de eventos, bajo el modelo de responsabilidad de PCI DSS; lo que viaja es el token.

Consideraciones de producción

Kafka no es gratis en complejidad operativa. Requiere definir correctamente el número de particiones (afecta el paralelismo máximo), el factor de replicación (afecta la durabilidad), la retención de mensajes (afecta el costo de almacenamiento) y las políticas de idempotencia de consumidores (afecta la consistencia). En entornos Kubernetes, un operador dedicado simplifica considerablemente el ciclo de vida del clúster.

La regla práctica que se confirma con el uso es: Kafka es la elección correcta cuando hay múltiples consumidores independientes que necesitan el mismo evento, cuando se necesita replay de eventos para depuración o migración, y cuando la disponibilidad del productor no puede depender de la disponibilidad del consumidor. Para comunicación request-response entre dos servicios que necesitan una respuesta inmediata, un REST síncrono sigue siendo más simple y adecuado.