{"id":128,"date":"2026-03-09T02:42:15","date_gmt":"2026-03-09T02:42:15","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/arquitectura-impulsada-por-eventos-2026-por-qu\/"},"modified":"2026-03-18T22:00:21","modified_gmt":"2026-03-18T22:00:21","slug":"arquitectura-impulsada-por-eventos-2026-por-qu","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/arquitectura-impulsada-por-eventos-2026-por-qu\/","title":{"rendered":"Arquitectura Impulsada por Eventos 2026: Por Qu\u00e9 los Microservicios se Est\u00e1n Pasando al Event Streaming"},"content":{"rendered":"

Hace unos meses estaba depurando un problema en producci\u00f3n<\/a> que me ten\u00eda completamente perdido. Ten\u00edamos un servicio de \u00f3rdenes que llamaba s\u00edncronamente a un servicio de inventario, que a su vez llamaba a un servicio de pagos, que llamaba a un servicio de notificaciones. Una cadena cl\u00e1sica de REST sobre REST. El problema: cuando el servicio de notificaciones se pon\u00eda lento (y se pon\u00eda lento bastante seguido), la latencia se propagaba hacia atr\u00e1s como un domin\u00f3. Las \u00f3rdenes empezaban a fallar. Los usuarios ve\u00edan errores 500. Mi tel\u00e9fono no paraba.<\/p>\n

Ese d\u00eda empec\u00e9 a tomar en serio lo que<\/a> varios colegas llevaban dici\u00e9ndome desde 2024: la arquitectura de microservicios que todos construimos durante la d\u00e9cada pasada tiene un problema estructural que los patrones de resiliencia tradicionales no resuelven del todo.<\/p>\n

El Problema Real con los Microservicios S\u00edncronos<\/h2>\n

Cuando digo “microservicios s\u00edncronos” me refiero a ese patr\u00f3n donde cada servicio habla directamente con otros a trav\u00e9s de HTTP o gRPC, esperando una respuesta antes de continuar. Es intuitivo. Es f\u00e1cil de debuggear localmente. Y durante a\u00f1os funcion\u00f3 razonablemente bien.<\/p>\n

El problema es el acoplamiento temporal. Dos servicios que se comunican s\u00edncronamente est\u00e1n acoplados en el<\/a> tiempo \u2014 los dos tienen que estar disponibles al mismo tiempo para que la operaci\u00f3n funcione. Suena obvio cuando lo dices as\u00ed, pero las consecuencias son m\u00e1s profundas de lo que<\/a> parece.<\/p>\n

En un sistema con 15 servicios donde cada llamada tiene 99.9% de disponibilidad, la disponibilidad compuesta de una cadena de 10 llamadas es aproximadamente 99%. Eso son unas 7 horas de downtime al mes. Empiezas a a\u00f1adir circuit breakers, retries con backoff exponencial, timeouts en cascada… y de repente tienes un sistema complicado que sigue fallando, solo que de maneras m\u00e1s interesantes.<\/p>\n

No estoy diciendo que los microservicios s\u00edncronos sean malos per se. Para ciertas operaciones \u2014 consultas de lectura, validaciones en tiempo real, operaciones que genuinamente necesitan una respuesta inmediata \u2014 siguen siendo la herramienta correcta. Lo que<\/a> cambi\u00f3 en los \u00faltimos dos a\u00f1os es la forma en que los equipos piensan sobre qu\u00e9 operaciones realmente necesitan ser s\u00edncronas.<\/p>\n

La respuesta, sorprendentemente, es que son muchas menos de las que cre\u00edamos.<\/p>\n

Qu\u00e9 Cambi\u00f3 en 2025-2026<\/h2>\n

El event streaming<\/a> no es nuevo. Kafka existe desde 2011. Lo que<\/a> s\u00ed cambi\u00f3 es la madurez del ecosistema alrededor de \u00e9l y, honestamente, el costo de operarlo.<\/p>\n

Redpanda<\/strong> \u2014 que nunca dependi\u00f3 de ZooKeeper y usa Raft desde su origen, con compatibilidad casi perfecta con la API de Kafka \u2014 baj\u00f3 significativamente la barrera de entrada. En mi equipo pasamos de gestionar un cl\u00faster de Kafka con 5 brokers m\u00e1s ZooKeeper a un cl\u00faster de Redpanda con 3 nodos. El consumo de memoria cay\u00f3 a la mitad. No tengo que mentir: fue un alivio operacional real.<\/p>\n

Tambi\u00e9n madur\u00f3 mucho el patr\u00f3n Transactional Outbox<\/strong>. Antes, la pregunta “\u00bfc\u00f3mo garantizo que el evento se publique si la base de datos<\/a> falla a mitad de la transacci\u00f3n?” no ten\u00eda una respuesta limpia. Ahora hay librer\u00edas s\u00f3lidas \u2014 Debezium para CDC, Transactional Outbox con soporte nativo en varios ORMs \u2014 que hacen esto manejable.<\/p>\n

Y por supuesto, Apache Kafka 4.0<\/strong> sali\u00f3 en 2025 con el modo KRaft estable para producci\u00f3n<\/a>, lo que<\/a> simplific\u00f3 bastante el modelo operacional para quienes no quer\u00edan cambiar de Kafka.<\/p>\n

C\u00f3mo Se Ve Esto en C\u00f3digo Real<\/h2>\n

Dejame mostrarte el patr\u00f3n que adoptamos. Tenemos un servicio de \u00f3rdenes que antes hac\u00eda esto:<\/p>\n

# Antes: el servicio llama s\u00edncronamente a inventario, pagos, y notificaciones\nasync def create_order(order_data: OrderCreate) -> Order:\n    # Si cualquiera de estos falla, la orden falla\n    inventory_ok = await inventory_client.reserve(order_data.items)\n    if not inventory_ok:\n        raise HTTPException(status_code=409, detail="Stock insuficiente")\n\n    payment_result = await payment_client.charge(\n        user_id=order_data.user_id,\n        amount=order_data.total\n    )\n    if not payment_result.success:\n        # Ojo: aqu\u00ed ya reservamos inventario y tenemos que revertir\n        await inventory_client.release(order_data.items)\n        raise HTTPException(status_code=402, detail="Pago rechazado")\n\n    await notification_client.send_confirmation(order_data.user_id)\n\n    order = await db.save(order_data)\n    return order\n<\/code><\/pre>\n
El problema de esta versi\u00f3n, adem\u00e1s del acoplamiento temporal, es la l\u00f3gica de compensaci\u00f3n manual. Si el pago falla tengo que revertir el inventario. Si la notificaci\u00f3n falla… \u00bfqu\u00e9 hago? \u00bfRevierto todo? \u00bfDejo la orden sin confirmaci\u00f3n?<\/p>\n
Ahora el mismo flujo con event streaming<\/a>:<\/p>\n
# Despu\u00e9s: el servicio publica un evento y se desentiende del resto\nasync def create_order(order_data: OrderCreate) -> Order:\n    async with db.transaction():\n        # Guardamos la orden en estado PENDING\n        order = await db.save(Order(\n            **order_data.dict(),\n            status=OrderStatus.PENDING\n        ))\n\n        # Usando el patr\u00f3n Outbox: el evento se guarda en la misma transacci\u00f3n\n        # Debezium o un worker lo publica a Kafka despu\u00e9s\n        await db.save(OutboxEvent(\n            aggregate_id=order.id,\n            event_type="OrderCreated",\n            payload=order.to_event_dict(),\n            created_at=datetime.utcnow()\n        ))\n\n    # Respuesta inmediata al cliente con el estado PENDING\n    # Los servicios downstream reaccionan al evento de forma as\u00edncrona\n    return order\n\n# En el<\/a> servicio de inventario (consumidor independiente):\n@kafka_consumer(topic="orders", event_type="OrderCreated")\nasync def handle_order_created(event: OrderCreatedEvent):\n    result = await inventory.try_reserve(event.items)\n\n    # Publica su propio evento seg\u00fan el resultado\n    event_type = "InventoryReserved" if result.success else "InventoryFailed"\n    await kafka.publish("inventory-events", {\n        "order_id": event.order_id,\n        "type": event_type,\n        "reason": result.reason if not result.success else None\n    })\n<\/code><\/pre>\n
La diferencia fundamental: el servicio de \u00f3rdenes ya no sabe (ni le importa) si el inventario est\u00e1 disponible en ese momento. Publica un evento y termina. El servicio de inventario procesar\u00e1 el evento cuando pueda. Si est\u00e1 ca\u00eddo, lo procesar\u00e1 cuando se recupere \u2014 Kafka retiene los mensajes. La saga se ejecuta de forma as\u00edncrona, cada servicio publicando eventos que otros consumen.<\/p>\n
Esto no elimina la complejidad, ojo. La mueve. Ahora tienes que manejar la compensaci\u00f3n distribuida (el patr\u00f3n Saga), la eventual consistency, y los estados intermedios que el cliente puede ver. Pero es una complejidad m\u00e1s expl\u00edcita y, en mi experiencia, m\u00e1s manejable a largo plazo.<\/p>\n
El Gotcha que Me Cost\u00f3 Dos D\u00edas<\/h2>\n
Aqu\u00ed va la parte que m\u00e1s me duele recordar: el event ordering<\/strong>.<\/p>\n
Kafka garantiza el orden de los mensajes dentro de una partici\u00f3n. Lo que<\/a> yo no consider\u00e9 bien es que si particionas por order_id<\/code> (que es lo<\/a> natural), todos los eventos de la misma orden van a la misma partici\u00f3n. Perfecto. El problema vino cuando empezamos a particionar un topic por user_id<\/code> para paralelizar el procesamiento.<\/p>\n
Un usuario pod\u00eda tener dos \u00f3rdenes activas simult\u00e1neamente. Orden A se cre\u00f3 antes que Orden B, pero por un race condition en c\u00f3mo el producer asignaba particiones, el evento OrderCreated<\/code> de Orden B lleg\u00f3 antes al consumidor que el de Orden A. El servicio de inventario proces\u00f3 Orden B primero, reserv\u00f3 los \u00faltimos 2 items del stock, y cuando lleg\u00f3 Orden A ya no hab\u00eda stock \u2014 aunque Orden A se hab\u00eda creado antes.<\/p>\n
\u00bfLa soluci\u00f3n? Para este caso espec\u00edfico necesit\u00e1bamos que el orden relativo entre \u00f3rdenes del mismo usuario se preservara. Pasamos a particionar el topic de \u00f3rdenes tambi\u00e9n por user_id<\/code>. Suena simple en retrospectiva, pero encontrar el bug me tom\u00f3 dos d\u00edas de logs y mucho caf\u00e9.<\/p>\n
La lecci\u00f3n general: no asumas que el orden de procesamiento refleja el orden de creaci\u00f3n a menos que hayas dise\u00f1ado expl\u00edcitamente para eso. En sistemas event-driven el orden es algo que tienes que ganarte, no algo que viene gratis.<\/p>\n
\u00bfCu\u00e1ndo Tiene Sentido<\/a> y Cu\u00e1ndo No?<\/h2>\n
No voy a venderte que migres todo a eventos. Ser\u00eda la respuesta f\u00e1cil \u2014 y equivocada.<\/p>\n
Los casos donde el event streaming<\/a> realmente paga son:<\/p>\n