En Métricas te queremos ayudar a impulsar el crecimiento de tu empresa u organización
Contáctanos para solicitar mayor información sobre nuestros servicios y soluciones para ayudarte a hacer crecer tu organización.
Contactar
Los sistemas financieros modernos procesan millones de operaciones cada segundo. Una transferencia bancaria desencadena verificaciones de identidad, validaciones de saldo, registros contables y notificaciones al usuario, todo en fracciones de segundo.
Este nivel de coordinación no es posible con los enfoques tecnológicos tradicionales.
Durante décadas, las instituciones financieras construyeron sus plataformas sobre arquitecturas monolíticas donde todos los componentes dependían unos de otros.
Cuando el volumen de transacciones creció, estos sistemas comenzaron a mostrar sus limitaciones: cuellos de botella en procesamiento, tiempos de respuesta elevados y dificultad para incorporar nuevas funcionalidades sin afectar la operación existente.
Las fintech que compiten hoy en mercados como pagos instantáneos, crédito digital y open banking necesitan una infraestructura capaz de procesar eventos simultáneamente, escalar de forma independiente por componente y recuperarse ante fallos sin interrumpir la experiencia del usuario.
Event Driven Architecture, o arquitectura orientada a eventos, es el modelo que hace posible esta capacidad operativa.
En este artículo conocerás qué es, cómo funciona en el contexto financiero, por qué las fintechs la están adoptando y cuáles son sus beneficios, retos y tecnologías asociadas.
Event Driven Architecture es un patrón de diseño de software en el que los componentes de un sistema se comunican mediante eventos, es decir, notificaciones que indican que algo ha ocurrido.
En sistemas financieros, un evento puede ser la apertura de una cuenta, la autorización de un pago, la aprobación de un crédito o la detección de una transacción inusual. A diferencia de una solicitud tradicional, donde un servicio le pregunta a otro "¿puedes hacer esto?", un evento simplemente anuncia "esto acaba de suceder".
Esta distinción cambia fundamentalmente cómo los servicios se relacionan entre sí. En una arquitectura orientada a eventos, el servicio que genera el evento no necesita conocer quién lo va a procesar ni cuándo. El acoplamiento entre componentes se reduce drásticamente.
Una implementación típica de EDA en fintech incluye cuatro elementos esenciales.
Los productores de eventos son los servicios o sistemas que generan notificaciones cuando ocurre una acción relevante: el módulo de onboarding, el motor de pagos o el sistema de scoring crediticio.
El broker o bus de eventos es la infraestructura que recibe, almacena y distribuye los eventos hacia los consumidores correspondientes. Herramientas como Apache Kafka o AWS EventBridge cumplen esta función.
Los consumidores de eventos son los servicios que se suscriben a determinados tipos de eventos y actúan en consecuencia: el motor de KYC, el módulo de compliance, el sistema de notificaciones o el ledger contable.
El event store es el repositorio donde quedan registrados todos los eventos del sistema, lo que permite reconstruir el historial de operaciones, auditar transacciones y garantizar trazabilidad completa.
Cuando un usuario completa el proceso de apertura de cuenta en una app financiera, el sistema genera un evento llamado "Cuenta Creada". A partir de ese momento, múltiples servicios reaccionan en paralelo: el módulo de KYC inicia la verificación de identidad, el área de compliance registra la nueva relación comercial, el ledger crea la cuenta contable correspondiente y el sistema de notificaciones envía un mensaje de bienvenida al usuario. Todo ocurre de manera simultánea, sin que ningún servicio tenga que esperar la respuesta de otro.
Para entender el funcionamiento en la práctica, tomemos el ejemplo de apertura de una cuenta digital. El usuario completa el formulario de onboarding en la aplicación. El sistema genera el evento "Cuenta Creada" y lo publica en el broker de eventos. KYC recibe el evento e inicia la verificación documental. Compliance recibe el mismo evento y registra la operación para efectos regulatorios. El ledger crea la cuenta contable y asigna el número de cliente. El sistema de notificaciones envía la confirmación por correo electrónico y push notification. El data warehouse registra la actividad para reportes y analítica. Todos estos pasos ocurren de forma desacoplada y en paralelo, lo que reduce significativamente el tiempo total de procesamiento.
Una de las ventajas más relevantes para operaciones financieras es la tolerancia a fallos. Si el servicio de notificaciones cae temporalmente, los demás procesos continúan sin interrupción. Cuando el servicio se recupera, puede leer los eventos que no procesó desde el broker y ejecutar las notificaciones pendientes. Este mecanismo de reintentos automáticos garantiza que ningún evento quede sin procesar, lo que es crítico en contextos de alta regulación como el financiero.
En la comunicación síncrona, un servicio envía una solicitud y espera la respuesta antes de continuar. Esto genera dependencias directas y puede convertirse en un cuello de botella cuando los tiempos de respuesta aumentan o algún componente falla.
La comunicación asíncrona que caracteriza a EDA permite que el servicio publique el evento y continúe su ejecución sin esperar confirmación.
El procesamiento posterior ocurre de forma independiente. En sistemas financieros altamente transaccionales, esta diferencia tiene un impacto directo en el rendimiento y en la capacidad de escalar bajo demanda.
Los productos financieros digitales actuales operan bajo expectativas de inmediatez. Los pagos instantáneos, las transferencias SPEI, la emisión de tarjetas en tiempo real y la aprobación automática de créditos requieren que múltiples procesos ocurran en milisegundos. Una arquitectura basada en llamadas sincrónicas encadenadas no puede sostenerse a ese ritmo sin degradar la experiencia del usuario.
Con EDA, los componentes del sistema pueden escalar de manera independiente según la carga que reciben. Si el volumen de pagos se incrementa durante una campaña de fin de año, el servicio de autorización puede escalar horizontalmente sin necesidad de rediseñar toda la plataforma. Esto permite que las fintechs crezcan en usuarios y transacciones sin comprometer la estabilidad del sistema.
En organizaciones con múltiples equipos de ingeniería, el desacoplamiento que ofrece EDA permite que cada equipo diseñe, despliegue y actualice sus servicios de forma autónoma. Esto acelera los ciclos de desarrollo y reduce el riesgo de que un cambio en un componente afecte el funcionamiento de otros.
En un monolito, todos los módulos del sistema comparten la misma base de código y se despliegan como una unidad. Cualquier fallo puede afectar la totalidad de la plataforma, y la escalabilidad requiere replicar el sistema completo, no solo el componente bajo mayor demanda.
La comunicación mediante APIs REST o gRPC resuelve parte del problema al separar servicios, pero mantiene un modelo de comunicación síncrona. En sistemas con alta concurrencia transaccional, esto genera latencia acumulada y puntos de fallo que pueden propagar errores en cadena.
EDA introduce comunicación desacoplada, procesamiento paralelo y mayor resiliencia. Los servicios no dependen de la disponibilidad inmediata de otros componentes y el sistema puede absorber picos de demanda sin degradarse. Para fintechs que procesan miles de transacciones simultáneas, esta diferencia es determinante.
Cada pago desencadena un flujo de eventos: autorización, liquidación, conciliación y notificación al usuario. Con EDA, estos procesos ocurren en paralelo y cada uno puede escalar de forma independiente según el volumen de operaciones.
Cuando un usuario solicita un crédito, el sistema genera un evento que activa simultáneamente el motor de scoring, el módulo de compliance y el proceso de validación documental. La resolución final se emite en segundos, no en horas.
La solicitud de emisión de una tarjeta digital genera eventos que coordinan personalización, activación y entrega de credenciales, permitiendo que el usuario tenga su tarjeta disponible en la app de forma inmediata.
Los eventos en tiempo real permiten que los sistemas de detección de fraude y prevención de lavado de activos analicen patrones de comportamiento a medida que ocurren, no de manera retrospectiva. Las alertas automáticas se emiten en el momento en que se detecta una anomalía.
La compartición de datos entre instituciones financieras regulada por marcos de open finance requiere sincronización en tiempo real entre sistemas de distintas organizaciones. EDA facilita esta coordinación mediante eventos estandarizados que viajan entre plataformas.
El core financiero es el sistema que registra todas las operaciones, gestiona los productos financieros y actúa como fuente de verdad contable de la organización. Su integración con una arquitectura orientada a eventos determina en gran medida la velocidad y confiabilidad con la que una fintech puede operar.
Cada apertura de cuenta, movimiento de fondos, pago procesado o crédito otorgado genera un evento que debe impactar el core de manera consistente. Una integración bien diseñada permite que el core reciba estos eventos sin convertirse en un cuello de botella y sin que los demás servicios dependan directamente de su disponibilidad.
Para fintechs en crecimiento, esta arquitectura reduce la dependencia del core como punto único de integración, acelera el lanzamiento de nuevos productos y facilita la evolución tecnológica sin necesidad de reemplazar la plataforma completa.
Un core ledger-first coloca el registro financiero en el centro de todas las operaciones. La consistencia contable no es una consecuencia del procesamiento, sino su punto de partida. Cada operación queda registrada en el ledger antes de que se considere completada.
En este modelo, los eventos del sistema producen entradas directas en el ledger: débitos, créditos, comisiones, reversiones y ajustes. Cada entrada está vinculada al evento que la originó, lo que permite reconstruir el estado financiero en cualquier punto del tiempo.
El historial de eventos combinado con el registro ledger ofrece una trazabilidad completa que simplifica los procesos de auditoría interna, cumplimiento regulatorio y conciliación contable. Esto es especialmente relevante en jurisdicciones con altas exigencias de reporte financiero.
La escalabilidad horizontal permite que los componentes del sistema crezcan de manera independiente según la demanda, sin necesidad de replicar la plataforma completa.
El procesamiento en tiempo real garantiza que los usuarios reciban respuestas inmediatas y que los procesos internos ocurran de forma simultánea.
La mayor resiliencia se traduce en sistemas que toleran fallos parciales sin interrumpir la operación general, gracias a mecanismos de reintento y procesamiento diferido.
La experiencia del usuario mejora cuando los tiempos de respuesta se reducen y las notificaciones llegan en el momento exacto en que ocurre cada evento relevante.
El menor tiempo de lanzamiento de nuevos productos resulta de la independencia entre equipos y servicios, que permite desarrollar y desplegar funcionalidades sin afectar la operación existente.
La observabilidad y el monitoreo se benefician del registro centralizado de eventos, que ofrece visibilidad completa sobre el estado del sistema en tiempo real.
La complejidad operacional aumenta cuando el número de servicios y flujos de eventos crece. Coordinar, documentar y mantener un ecosistema distribuido requiere disciplina de ingeniería y herramientas especializadas.
La consistencia eventual implica que, a diferencia de los sistemas síncronos, los datos pueden tardar un breve período en reflejarse de manera uniforme en todos los componentes. En contextos financieros, gestionar este comportamiento requiere diseño cuidadoso.
La gestión de eventos duplicados es un desafío real cuando los mecanismos de reintento pueden enviar el mismo evento más de una vez. Los sistemas consumidores deben estar preparados para detectar y descartar duplicados.
La idempotencia en transacciones financieras garantiza que procesar el mismo evento varias veces produzca el mismo resultado, evitando cargos o créditos duplicados.
La observabilidad distribuida requiere herramientas de rastreo que permitan seguir el recorrido de un evento a través de múltiples servicios.
El gobierno de eventos implica definir estándares para el formato, versionado y ciclo de vida de los eventos, algo que se vuelve crítico a medida que el sistema crece.
Apache Kafka es la plataforma de streaming de eventos más adoptada en la industria financiera por su capacidad de procesamiento a gran escala, durabilidad del almacenamiento de eventos y soporte para múltiples consumidores.
RabbitMQ es una solución de mensajería orientada a colas, adecuada para flujos de trabajo con requisitos de enrutamiento complejo y menor volumen de eventos.
AWS EventBridge ofrece integración nativa con el ecosistema de servicios de Amazon Web Services, facilitando la construcción de arquitecturas orientadas a eventos en la nube.
Google Pub/Sub es el servicio gestionado de Google Cloud para mensajería asíncrona, con alta disponibilidad y escalabilidad automática.
Azure Event Hubs está optimizado para la ingesta masiva de eventos en tiempo real dentro del ecosistema de Microsoft Azure.
Event Sourcing y CQRS son patrones de diseño complementarios a EDA. Event Sourcing almacena el estado del sistema como una secuencia de eventos en lugar de como un estado actual. CQRS separa las operaciones de escritura y lectura para optimizar el rendimiento en cada caso.
Existen indicadores claros que sugieren que una plataforma financiera ha superado las capacidades de su arquitectura actual.
Los problemas frecuentes de escalabilidad, donde el sistema se degrada bajo picos de demanda, son una señal directa. Las dependencias excesivas entre servicios que hacen que un fallo en un componente afecte a toda la operación son otra señal relevante.
El crecimiento acelerado de transacciones que supera la capacidad de procesamiento sincrónico, la necesidad de respuestas en tiempo real que la arquitectura actual no puede ofrecer y la existencia de múltiples productos financieros que deben coordinarse sin acoplamiento son indicadores que justifican una transición hacia EDA.
El primer paso es identificar los eventos de negocio más relevantes: qué acciones del usuario o del sistema merecen generar una notificación y cuáles son los servicios interesados en cada tipo de evento.
Diseñar dominios funcionales claros permite agrupar servicios relacionados y definir fronteras de responsabilidad que faciliten el mantenimiento y la evolución del sistema.
Definir contratos de eventos establece el formato, la versión y la estructura de cada tipo de evento, asegurando que productores y consumidores se comuniquen con consistencia.
Implementar brokers de mensajería con la tecnología adecuada al volumen y los requisitos de latencia de la operación es el siguiente paso técnico fundamental.
Monitorear y auditar eventos de forma continua garantiza visibilidad sobre el comportamiento del sistema y facilita la detección temprana de anomalías.
Integrar el ledger y el core financiero dentro del flujo de eventos asegura que toda operación quede registrada con trazabilidad completa desde su origen hasta su impacto contable.
Event Driven Architecture se ha consolidado como uno de los pilares tecnológicos de las fintechs modernas. Permite escalar operaciones, reducir dependencias entre equipos y procesar eventos financieros en tiempo real con resiliencia y trazabilidad.
Combinada con una arquitectura modular y un core ledger-first, ofrece la base técnica necesaria para lanzar, operar y evolucionar productos financieros digitales en mercados que exigen velocidad, confiabilidad y cumplimiento regulatorio.
La transición hacia este modelo no es trivial, pero las fintechs que la adoptan con rigor de ingeniería obtienen una ventaja competitiva difícil de replicar con infraestructuras heredadas.