Arquitectura Orientada a Eventos: El Paso que Sigue a los Microservicios

WAU Marketing
hace unos segundos
6 min de lectura

Si crees que partir tu monolito en microservicios fue la modernización, te tenemos una mala noticia: acabas de construir un montón de cajas modernas que siguen esperando a que el core las despierte por lotes. El verdadero salto no es trocear el sistema; es que el sistema reaccione solo, en el instante en que algo pasa.

En este blog ya defendimos partir el monolito en microservicios como un paso necesario para salir de un core rígido. Lo sostenemos. Pero hay una trampa silenciosa: puedes tener cincuenta microservicios impecables y, aun así, una arquitectura que sigue pensando en lotes. Si esos servicios solo se hablan cuando un proceso nocturno los recorre, o cuando alguien pregunta "¿hay algo nuevo?", no construiste un banco en tiempo real. Construiste un monolito repartido en pedazos.

El paso que sigue tiene nombre: arquitectura orientada a eventos. La idea es simple de enunciar y profunda en consecuencias. En lugar de que los sistemas se pregunten unos a otros por el estado de las cosas, cada hecho relevante —un pago confirmado, un intento de acceso sospechoso, un límite a punto de superarse— se publica como un evento en el momento en que ocurre, y todo el que necesite reaccionar lo hace de inmediato. El evento es la columna vertebral. El core deja de ser un archivo que se consulta y se vuelve un sistema que responde.

Microservicios resuelven cómo está organizado; los eventos resuelven cuándo reacciona

Conviene separar las dos cosas porque se confunden todo el tiempo. Los microservicios son una decisión de estructura: cómo divides el sistema en partes que se despliegan y evolucionan por separado. La arquitectura de eventos es una decisión de tiempo: cuándo y cómo esas partes se enteran de que algo cambió. Puedes tener lo primero sin lo segundo, y es justo ahí donde se atascan muchas modernizaciones: microservicios nuevos pegados con integraciones por lotes viejas.

La diferencia se nota cuando un hecho importa ya. Un pago entró. ¿El motor de fraude lo evalúa en ese segundo, o lo verá mañana cuando corra el batch? ¿El sistema de notificaciones avisa al cliente en el momento, o cuando le toque su ventana de proceso? En un diseño orientado a eventos, el pago se publica una vez y el motor de fraude, el de notificaciones, el de conciliación y el de límites reaccionan en paralelo, sin que nadie tenga que coordinarlos a mano.

Por qué un core batch no puede con el tiempo real

Aquí está el corazón del asunto. Un core que procesa por lotes no es "más lento": es estructuralmente incapaz de operar en tiempo real, porque su unidad de trabajo es la ventana de proceso, no el evento. El ejemplo más limpio que conocemos es Rabobank. Su sistema original de alertas vivía en el mainframe y era estable, pero entregar una alerta podía tardar entre cinco minutos y cinco horas, según el tipo de alerta y la ventana del batch, como documentó Axual, la empresa que rediseñó el sistema. Al reconstruirlo sobre una arquitectura de eventos con Apache Kafka, el viaje completo —desde que se confirma un pago hasta que la alerta llega al móvil— pasó a tomar uno o dos segundos, con la cadena de alertado ejecutándose en unos 120 milisegundos, según la misma fuente.

De cinco horas a un segundo no es una optimización; es otra física. Y no se logró comprando una computadora más rápida, sino cambiando la pregunta: en vez de "¿cuándo corremos el proceso?", el sistema asume "el evento ya pasó, reacciona". Apache Kafka, el motor de event streaming más usado en banca, es justamente la pieza que permite publicar esos hechos como un flujo continuo y dejar que muchos servicios los consuman a la vez.

Los eventos son donde el banco gana o pierde plata: el fraude

El caso donde el tiempo real deja de ser elegancia técnica y se vuelve dinero es la prevención de fraude. Aquí la diferencia entre reaccionar en el evento o en el lote es la diferencia entre bloquear una transacción fraudulenta o pagarla. El especialista en event streaming Kai Waehner documenta que el Bank of Ayudhya (Krungsri), uno de los mayores bancos de Tailandia, usa Apache Kafka para detectar y bloquear transacciones fraudulentas en menos de 60 segundos —algo imposible si el análisis ocurriera en un proceso nocturno. El mismo autor recopila otros casos de la industria: PayPal procesa más de 400,000 millones de eventos por día para tracking de comportamiento, monitoreo de comercios y detección de fraude; ING, Royal Bank of Canada, Capital One y Nordea aparecen usando event streaming para fraude, descarga del mainframe y reportería regulatoria en tiempo real (es un autor cercano al ecosistema de proveedores, por eso lo señalamos).

El punto neutral detrás de los ejemplos es claro: el fraude ocurre como un evento y solo se detiene reaccionando como un evento. Un core que se entera mañana llega tarde por definición.

Y los eventos son donde LATAM ya está jugando: pagos instantáneos

Si en alguna región esta discusión dejó de ser teórica, es la nuestra. Los pagos instantáneos volvieron obligatorio reaccionar al instante, y los números lo gritan. En Brasil, PIX iba camino de superar los 7,900 millones de transacciones mensuales en diciembre de 2025 y de mover unos 6.7 billones de dólares en el año, un 34% más que el anterior; desde su lanzamiento acumula 196,200 millones de transacciones y 16 billones de dólares movidos, con más de 170 millones de usuarios —el 93% de la población adulta—, según un estudio de EBANX difundido por GlobeNewswire. En México, el SPEI procesó alrededor de 7,000 millones de operaciones en 2025 —unas 222 por segundo y más de 14 millones diarias—, moviendo cerca de 347 billones de pesos, unas diez veces el PIB nominal del país, de acuerdo con un reporte de Bitso citado por El Cronista.

Un sistema de pagos que liquida 24/7 y al instante no admite un core que concilia al cierre. La conciliación en tiempo real, la actualización de saldos y la validación de límites tienen que pasar mientras el dinero se mueve, no horas después. Ese ritmo es, literalmente, un flujo de eventos; un core batch no puede seguirlo sin acumular riesgo, descalces y reclamos de clientes.

El nuevo estándar no es retrofit, es nacer así

Lo más revelador es cómo construyen los que empiezan de cero. La plataforma de core bancario en la nube 10x Banking decidió, casi desde el día uno de diseñar su arquitectura, publicar todos sus datos como eventos para alimentar un modelo de microservicios API-first, según el caso de Confluent (Confluent es un proveedor de la tecnología de streaming, lo señalamos). No es un parche sobre un mainframe: es un core concebido como un flujo de eventos desde el origen. Esa es la vara con la que ya se mide un core moderno.

Cómo lo vemos en WAU

En WAU no creemos que modernizar sea trocear el monolito y declarar victoria. Diseñamos el core para que los eventos sean su columna vertebral: cada pago, cada intento de fraude, cada cambio de límite se publica como un hecho en el momento en que ocurre, y los servicios que importan —conciliación, fraude, notificaciones, saldos— reaccionan en tiempo real, no en la próxima ventana de batch. Microservicios te dan un sistema ordenado; los eventos te dan un banco que responde. Para operar pagos instantáneos, frenar fraude y conciliar al vuelo, esa segunda parte no es opcional.

Si tu institución ya partió el monolito pero sigue moviéndose al ritmo del lote, ese es exactamente el siguiente paso que podemos ayudarte a dar. 👉 Agenda una conversación con nuestro equipo.