Arquitectura CQRS & Event Sourcing para Escala de 4.5B Registros
Cómo desacoplamos lecturas de escrituras usando CQRS y Event Sourcing para procesar 4.5 mil millones de registros con latencia de consulta sub-segundo.
Resultados Clave
El Desafío (El Cuello de Botella)
Dolor de Negocio
El cliente—un actor importante en el sector FinTech/Seguros—estaba efectivamente operando a ciegas. El libro mayor central se había vuelto tan pesado que generar reportes de conciliación de fin de mes tomaba más de 48 horas, frecuentemente expirando. La toma de decisiones en tiempo real—crucial para detección de fraude y evaluación de riesgo—era imposible debido a la latencia masiva de datos.
Dolor Técnico
La base de datos relacional legacy estaba siendo forzada a actuar como un “todólogo” (OLTP + OLAP), creando una pesadilla clásica de contención de recursos:
- Contención de Bloqueos: Operaciones de escritura pesadas durante horario laboral bloqueaban filas, causando que las consultas de lectura del dashboard se colgaran o expiraran.
- Parálisis de Indexación: Una única tabla monolítica creció a 4.5 mil millones de filas. Agregar un nuevo índice para optimizar consultas tomaba días y requería tiempo de inactividad planificado, congelando la iteración del producto.
- Acoplamiento Fuerte: La arquitectura monolítica acoplaba la ingesta de datos directamente a la interfaz de usuario. Un pico en el volumen de transacciones degradaba directamente la experiencia del personal de soporte.
La Arquitectura (La Solución)
Estrategia
Nos alejamos de la mentalidad CRUD e implementamos un patrón estricto de CQRS (Command Query Responsibility Segregation) combinado con Event Sourcing. Esto nos permitió escalar lecturas y escrituras de forma independiente.
La Lógica
Desacoplar Escrituras de Lecturas: Separamos el “Lado de Escritura” (Commands) del “Lado de Lectura” (Queries). El modelo de escritura se enfocó únicamente en ingesta de alta velocidad y validación, ignorando lógica de joins complejos.
La Verdad Inmutable: La “Fuente de Verdad” pasó de una base de datos relacional mutable a un Event Store de solo-escritura (append-only) usando Kafka/Pulsar. Esto aseguró un rastro de auditoría perfecto de cada cambio de estado (ej., PaymentInitiated, PaymentSettled), habilitando depuración de “Viaje en el Tiempo”.
Persistencia Políglota (Projections): Reconocimos que una sola base de datos no puede satisfacer todas las necesidades. Construimos “Read Models” especializados (Projections) consumiendo el flujo de eventos:
- Elasticsearch: Optimizado para búsqueda difusa y criterios de filtrado complejos usados por el personal de soporte.
- Data Lake (S3/Parquet): Optimizado para cargas de trabajo OLAP por lotes. Usamos estrategias de partición (Año/Mes/Día) para permitir al equipo de Data Science consultar años de historial usando Athena/Presto sin tocar producción.
- Redis: Optimizado para búsquedas clave-valor (ej., “Obtener Saldo de Usuario”) con latencia sub-milisegundo.
El Resultado
- Velocidad Operacional: El tiempo de generación de reportes cayó de 48 horas a Casi Tiempo Real (<5 segundos de lag).
- Escalabilidad: El sistema manejó exitosamente la carga de 4.5B registros. Los picos de escritura ya no afectaban el rendimiento de lectura, al ser amortiguados por el bus de eventos.
- Democratización de Datos: Habilitó al equipo de Data Science a ejecutar consultas complejas e intensivas en recursos sobre el Data Warehouse sin afectar el rendimiento de producción ni arriesgar timeouts en la UI.