{"id":494,"date":"2026-03-09T10:38:12","date_gmt":"2026-03-09T10:38:12","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/event-driven-architecture-in-2026-why-microservice\/"},"modified":"2026-03-18T22:31:28","modified_gmt":"2026-03-18T22:31:28","slug":"event-driven-architecture-in-2026-why-microservice","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/event-driven-architecture-in-2026-why-microservice\/","title":{"rendered":"Migramos 5 microservicios a event streaming y esto fue lo que encontramos"},"content":{"rendered":"

Era martes, alrededor de las 2am. No el t\u00edpico viernes-de-despliegue-que-sale-mal, sino un martes aburrido. Hab\u00edamos subido un cambio al servicio de inventario esa tarde \u2014 nada dram\u00e1tico, una validaci\u00f3n extra en el endpoint de stock \u2014 y dos horas despu\u00e9s lleg\u00f3 el primer Slack de nuestro sistema de monitoreo. Y luego otro. Y luego ya era yo con una taza de caf\u00e9 fr\u00edo mirando un grafo de Grafana donde las latencias del servicio de pedidos hab\u00edan pasado de 120ms a m\u00e1s de 8 segundos.<\/p>\n

El problema: nuestro servicio de pedidos llamaba de forma s\u00edncrona al servicio de inventario. El de inventario llamaba al de pricing para calcular el costo actualizado. El de pricing, a su vez, necesitaba confirmar ciertas reglas con inventario. S\u00ed \u2014 un ciclo. Nadie lo hab\u00eda documentado expl\u00edcitamente, pero ah\u00ed estaba, enterrado en semanas de desarrollo incremental. Cuando inventario empez\u00f3 a responder lento bajo la nueva validaci\u00f3n, toda la cadena colaps\u00f3.<\/p>\n

\u00c9ramos cinco personas. Cuatro microservicios que llevaban un a\u00f1o en producci\u00f3n<\/a> m\u00e1s uno reci\u00e9n separado del monolito. Y esa noche, mientras reconstru\u00edamos el flujo de llamadas en una<\/a> pizarra virtual a las<\/a> 3am, fue cuando uno de mis compa\u00f1eros dijo algo que me qued\u00f3 dando vueltas: “Si esto fuera basado en eventos, al menos el fallo estar\u00eda contenido.”<\/p>\n

Por Qu\u00e9 el Modelo Request-Response se Quiebra Cuando los Servicios se Hablan Entre S\u00ed<\/h2>\n

Mira, el patr\u00f3n s\u00edncrono tiene sentido<\/a> cuando tu arquitectura es simple. Un cliente llama a una API<\/a>, la API responde. Perfecto. Pero cuando los microservicios<\/a> empiezan a llamarse entre s\u00ed \u2014 lo que<\/a> inevitablemente pasa en cuanto el sistema crece \u2014 se acumulan problemas que no son obvios hasta que<\/a> ya duelen.<\/p>\n

El primero es el acoplamiento temporal. Si el servicio A necesita que B est\u00e9 disponible para completar una operaci\u00f3n, A y B est\u00e1n acoplados en tiempo real. No importa que tengan APIs separadas y bases de datos<\/a> distintas: en el momento en que uno falla, el otro tambi\u00e9n falla (o espera). En nuestro caso, un servicio de inventario lento propag\u00f3 su lentitud a cuatro servicios m\u00e1s.<\/p>\n

El segundo es m\u00e1s sutil y, en mi experiencia, m\u00e1s dif\u00edcil de notar hasta que<\/a> ya est\u00e1 roto: la distribuci\u00f3n de responsabilidades se distorsiona. Cuando A llama a B para obtener informaci\u00f3n, \u00bfqui\u00e9n es responsable de reintentar si B falla? \u00bfA? \u00bfCon qu\u00e9 l\u00f3gica de backoff? \u00bfDurante cu\u00e1nto tiempo? En la pr\u00e1ctica, cada equipo lo implementa diferente, y terminas con cinco estrategias de<\/a> retry distintas que interact\u00faan de maneras impredecibles.<\/p>\n

Despu\u00e9s del incidente empec\u00e9 a documentar cu\u00e1ntas llamadas s\u00edncronas cruzadas ten\u00edamos. El n\u00famero fue inc\u00f3modo: 23 endpoints de API interna que depend\u00edan de respuestas s\u00edncronas de otros servicios.<\/p>\n

Ah\u00ed fue cuando event streaming<\/a> dej\u00f3 de ser un tema de conferencias y pas\u00f3 a ser una necesidad concreta. El modelo es distinto: en vez de que A le pida informaci\u00f3n a B, A publica un evento (“pedido.creado”) y B lo consume cuando puede. B no necesita estar disponible en el momento exacto en que A procesa. Si B est\u00e1 ca\u00eddo, el evento queda en el stream esperando. Cuando B vuelve, lo procesa. El fallo est\u00e1 contenido.<\/p>\n

Claro que esto introduce su propio set de complejidad \u2014 y eso lo aprend\u00ed de primera mano durante las semanas siguientes.<\/p>\n

Tres Semanas Configurando Kafka 3.7 con un Equipo de Cinco Personas<\/h2>\n

No \u00e9ramos expertos en Kafka. Yo hab\u00eda hecho algunos tutoriales y un proyecto peque\u00f1o dos a\u00f1os atr\u00e1s, pero en producci\u00f3n<\/a> a escala real \u2014 no. As\u00ed que lo primero fue ser honestos sobre eso y reservar tres semanas para la migraci\u00f3n del primer servicio (el de notificaciones, que ten\u00eda el menor riesgo).<\/p>\n

Kafka 3.7 simplific\u00f3 bastante la configuraci\u00f3n con KRaft \u2014 ya no necesitas ZooKeeper separado, lo cual nos quit\u00f3 una capa de infraestructura que no quer\u00edamos mantener. Para el stack de Python que us\u00e1bamos (FastAPI + aiokafka), la configuraci\u00f3n b\u00e1sica del producer qued\u00f3 as\u00ed:<\/p>\n

from aiokafka import AIOKafkaProducer\nimport json, uuid\nfrom datetime import datetime\n\nasync def get_producer() -> AIOKafkaProducer:\n    producer = AIOKafkaProducer(\n        bootstrap_servers="kafka:9092",\n        # acks='all' garantiza que el mensaje lleg\u00f3 a todas las r\u00e9plicas\n        acks="all",\n        # enable_idempotence evita duplicados si el producer reintenta\n        enable_idempotence=True,\n        value_serializer=lambda v: json.dumps(v).encode("utf-8"),\n        # lz4 tiene buen balance velocidad\/ratio para payloads JSON\n        compression_type="lz4",\n    )\n    await producer.start()\n    return producer\n\nasync def publish_order_event(\n    producer: AIOKafkaProducer,\n    order_id: str,\n    event_type: str,\n    payload: dict,\n):\n    event = {\n        "event_id": str(uuid.uuid4()),\n        "event_type": event_type,  # e.g. "order.created", "order.cancelled"\n        "order_id": order_id,\n        "timestamp": datetime.utcnow().isoformat(),\n        "payload": payload,\n    }\n    await producer.send_and_wait(\n        topic="orders",\n        # La clave garantiza que eventos del mismo pedido van a la misma partici\u00f3n\n        key=order_id.encode("utf-8"),\n        value=event,\n    )\n<\/code><\/pre>\n
El enable_idempotence=True<\/code> fue algo que no ten\u00edamos en la primera versi\u00f3n y que nos cost\u00f3: sin eso, en ciertos escenarios de retry el producer puede duplicar mensajes. Lo descubrimos porque en staging empezamos a ver notificaciones dobles a usuarios de prueba. Nada catastr\u00f3fico, pero suficiente para que alguien revisara la documentaci\u00f3n con m\u00e1s cuidado.<\/p>\n
Un problema m\u00e1s interesante fue el sizing de particiones. Para un topic de pedidos con volumen moderado configuramos inicialmente 3 particiones. Cuando empezamos a escalar consumers, nos dimos cuenta de que Kafka limita el paralelismo al n\u00famero de particiones \u2014 no puedes tener m\u00e1s consumers activos en un grupo que particiones en el topic. Tuvimos que aumentar a 12, y cambiar el n\u00famero de particiones en un topic existente tiene implicaciones en el orden de los mensajes si usas claves. Hay que planearlo desde el principio, no despu\u00e9s.<\/p>\n
Lo Que Me Dej\u00f3 Completamente Confundido: Consumer Groups y la Sem\u00e1ntica de Exactly-Once<\/h2>\n
Okay, necesito ser honesto aqu\u00ed. Entend\u00ed consumer groups conceptualmente antes de la migraci\u00f3n. Los le\u00ed en la documentaci\u00f3n, vi algunos diagramas. Pero lo que<\/a> no entend\u00ed \u2014 hasta que<\/a> lo vi roto en producci\u00f3n<\/a> \u2014 es la interacci\u00f3n entre consumer groups, offsets y rebalancing cuando corres m\u00faltiples instancias.<\/p>\n
La situaci\u00f3n concreta: ten\u00edamos el servicio de notificaciones leyendo del topic de pedidos. Todo funcionaba en staging con una instancia. Cuando desplegamos en producci\u00f3n con<\/a> dos instancias para redundancia, el sistema empez\u00f3 a comportarse de forma err\u00e1tica. Algunos eventos se procesaban dos veces, otros no se procesaban.<\/p>\n
El problema era que manej\u00e1bamos el commit de offsets mal. Hac\u00edamos consumer.commit()<\/code> justo despu\u00e9s de<\/a> recibir el mensaje, antes de procesarlo. Si el procesamiento fallaba a mitad camino, el offset ya estaba commiteado y el mensaje se perd\u00eda silenciosamente. La soluci\u00f3n es commitear solo despu\u00e9s de<\/a> que el procesamiento sea exitoso:<\/p>\n
from aiokafka import AIOKafkaConsumer\nimport logging\n\nlogger = logging.getLogger(__name__)\n\nasync def consume_orders():\n    consumer = AIOKafkaConsumer(\n        "orders",\n        bootstrap_servers="kafka:9092",\n        group_id="notifications-service",\n        # 'earliest' para no perderse mensajes si el consumer arranca nuevo\n        auto_offset_reset="earliest",\n        # Manejamos el commit manualmente para control preciso\n        enable_auto_commit=False,\n        value_deserializer=lambda m: json.loads(m.decode("utf-8")),\n    )\n    await consumer.start()\n\n    try:\n        async for msg in consumer:\n            event = msg.value\n            try:\n                # Primero procesamos, luego commiteamos\n                await handle_order_event(event)\n                await consumer.commit()\n            except Exception as e:\n                # No commiteamos \u2014 el mensaje se reintentar\u00e1\n                # En producci\u00f3n<\/a>, aqu\u00ed enviamos a un dead letter topic\n                logger.error(\n                    f"Error procesando evento {event.get('event_id')}: {e}"\n                )\n    finally:\n        await consumer.stop()\n<\/code><\/pre>\n
Lo que me sorprendi\u00f3 \u2014 y esto no lo vi en ning\u00fan tutorial \u2014 es lo<\/a> traicionera que es la sem\u00e1ntica de exactly-once en la pr\u00e1ctica. T\u00e9cnicamente Kafka la soporta desde la versi\u00f3n 0.11 con transacciones, pero la implementaci\u00f3n real requiere que tanto el consumer como el producer participen en la transacci\u00f3n, y que el sistema destino soporte idempotencia. En la mayor\u00eda de los casos pr\u00e1cticos termin\u00e1s con at-least-once delivery y dise\u00f1\u00e1s tus handlers para ser idempotentes. No es lo mismo, pero funciona si eres disciplinado con eso desde el principio. Yo pensaba que exactly-once ser\u00eda la norma y que ser\u00eda f\u00e1cil de activar \u2014 result\u00f3 que at-least-once con idempotencia es lo que<\/a> la mayor\u00eda de equipos usa en la pr\u00e1ctica.<\/p>\n
No estoy 100% seguro de que nuestro enfoque actual escale bien m\u00e1s all\u00e1 de los 50.000 eventos por hora que manejamos en pico. Para vol\u00famenes m\u00e1s altos probablemente habr\u00eda que revisar la configuraci\u00f3n de<\/a> batching y las estrategias de<\/a> procesamiento.<\/p>\n
Un A\u00f1o Despu\u00e9s: M\u00e9tricas Reales y Mi Recomendaci\u00f3n Sin Rodeos<\/h2>\n
Doce meses despu\u00e9s de<\/a> la migraci\u00f3n inicial \u2014 los cinco servicios en total, los \u00faltimos tres fueron bastante m\u00e1s r\u00e1pidos porque ya sab\u00edamos qu\u00e9 hacer \u2014 los n\u00fameros son concretos.<\/p>\n
La latencia promedio del servicio de pedidos baj\u00f3 de 340ms a 45ms. Eso porque eliminamos las llamadas s\u00edncronas en cadena: ahora el servicio publica el evento y termina, sin esperar respuestas de otros servicios. El procesamiento downstream ocurre de forma as\u00edncrona.<\/p>\n
M\u00e1s importante para m\u00ed: no hemos tenido un incidente de cascada desde la migraci\u00f3n. Hemos tenido fallos individuales \u2014 el servicio de notificaciones estuvo ca\u00eddo tres horas en noviembre por un problema de configuraci\u00f3n \u2014 pero el impacto se limit\u00f3 a ese servicio. Los eventos se acumularon en el topic de Kafka y cuando el servicio volvi\u00f3, los proces\u00f3 sin p\u00e9rdida de datos<\/a>.<\/p>\n
El costo operativo subi\u00f3. Kafka requiere atenci\u00f3n: monitorear consumer lag, alertar cuando un grupo se queda atr\u00e1s, gestionar la retenci\u00f3n de logs. Nosotros usamos Confluent Cloud para no tener que operar el cluster nosotros mismos, y eso tiene un costo mensual que con REST<\/a> era cero. Para un equipo peque\u00f1o, eso importa y hay que incluirlo en la evaluaci\u00f3n.<\/p>\n
\u00bfLo har\u00eda igual de nuevo? B\u00e1sicamente s\u00ed, con dos cambios. Primero: empezar\u00eda con m\u00e1s particiones desde el principio \u2014 12 m\u00ednimo para topics de alta actividad, no 3 que luego hay que migrar. Segundo: definir\u00eda un esquema de eventos m\u00e1s r\u00edgido desde el d\u00eda uno. Usamos JSON libre durante los primeros meses y cuando quisimos agregar Schema Registry para validar contratos entre servicios, tuvimos que migrar mensajes existentes. Fue m\u00e1s trabajo del necesario.<\/p>\n
Si tienes m\u00e1s de tres microservicios llam\u00e1ndose entre s\u00ed de forma s\u00edncrona y est\u00e1s viendo fallos en cascada o latencias que se propagan, migrar a event streaming<\/a> vale la<\/a> inversi\u00f3n. Empieza con el servicio que tiene la mayor cantidad de llamadas s\u00edncronas entrantes y que sea el menos cr\u00edtico \u2014 \u00fasalo como proyecto de aprendizaje real. La curva de aprendizaje existe (consumer groups, offset management, particiones), pero no es insuperable en un equipo peque\u00f1o. Para proyectos<\/a> nuevos, yo dise\u00f1ar\u00eda con eventos desde el principio, antes de que el grafo de dependencias s\u00edncronas se vuelva lo que era el nuestro a las 2am de ese martes.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Era martes, alrededor de las 2am. No el t\u00edpico viernes-de-despliegue-que-sale-mal, sino un martes aburrido.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-494","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/494","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=494"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/494\/revisions"}],"predecessor-version":[{"id":775,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/494\/revisions\/775"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=494"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=494"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=494"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}