{"id":170,"date":"2026-03-09T03:53:41","date_gmt":"2026-03-09T03:53:41","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/arquitectura-impulsada-por-eventos-2026-por-qu-los\/"},"modified":"2026-03-18T22:00:21","modified_gmt":"2026-03-18T22:00:21","slug":"arquitectura-impulsada-por-eventos-2026-por-qu-los","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/arquitectura-impulsada-por-eventos-2026-por-qu-los\/","title":{"rendered":"Arquitectura Impulsada por Eventos en 2026: Por Qu\u00e9 Dej\u00e9 de Pelear con REST Entre Microservicios"},"content":{"rendered":"

Hace unos diez meses, un servicio de notificaciones llam\u00f3 a un servicio de inventario, que llam\u00f3 a un servicio de precios, que estaba ca\u00eddo por un deploy<\/a> mal sincronizado. La cadena entera se fue al piso. Era viernes por la tarde, ten\u00edamos tres usuarios reportando errores raros en checkout, y yo estaba intentando trazar qu\u00e9 hab\u00eda llamado a qu\u00e9 revisando logs de cuatro servicios diferentes en paralelo.<\/p>\n

Ese fue el momento en que decid\u00ed que ya no quer\u00eda m\u00e1s arquitectura s\u00edncrona entre microservicios.<\/p>\n

No porque REST sea malo \u2014 en el<\/a> boundary entre frontend y backend sigue siendo perfectamente razonable. Sino porque usar REST para comunicaci\u00f3n interna entre servicios es b\u00e1sicamente construir dependencias de tiempo de ejecuci\u00f3n que no se ven hasta que<\/a> algo explota en producci\u00f3n<\/a>.<\/p>\n

El Problema Real con Microservicios S\u00edncronos (No Es Lo Que<\/a> Crees)<\/h2>\n

Cuando empec\u00e9 a investigar event streaming<\/a>, asum\u00ed que el beneficio principal era rendimiento. Pens\u00e9: “okay, Kafka es r\u00e1pido, mis requests van a ser m\u00e1s r\u00e1pidos.” Estaba completamente equivocado sobre el por qu\u00e9<\/a> vale la pena<\/a>.<\/p>\n

El problema con los microservicios<\/a> s\u00edncronos no es velocidad. Es acoplamiento temporal. Cuando el Servicio A hace un HTTP request al Servicio B, en ese momento exacto ambos servicios necesitan estar vivos, responder dentro del timeout, y estar de acuerdo sobre el contrato de la API. Si cualquiera de esas tres cosas falla, el error se propaga hacia arriba. Y en un sistema de 8-10 servicios (que es donde estaba mi equipo \u2014 somos cuatro ingenieros manejando una plataforma de e-commerce con servicios separados para inventario, \u00f3rdenes, notificaciones, pagos, b\u00fasqueda y usuarios), las cadenas de dependencias se vuelven imposibles de razonar.<\/p>\n

El circuit breaker pattern mitiga esto, pero no lo resuelve. Estaba usando Resilience4j en nuestros servicios de Spring Boot y aun as\u00ed terminaba debuggeando cascadas de fallbacks que produc\u00edan estados inconsistentes dif\u00edciles de reproducir.<\/p>\n

Lo que event streaming<\/a> resuelve es diferente: el productor publica un evento y no le importa qui\u00e9n lo consume ni cu\u00e1ndo. El consumidor procesa cuando puede. El desacoplamiento temporal es la feature, no un side effect.<\/p>\n

Kafka vs Redpanda en 2026:<\/a> Eleg\u00ed Mal la Primera Vez<\/h2>\n

Empec\u00e9 con Apache Kafka 3.8. Documentaci\u00f3n s\u00f3lida, ecosistema enorme, Confluent Schema Registry disponible. Pas\u00e9 dos semanas<\/a> configurando el cluster en nuestro entorno de staging \u2014 Kubernetes<\/a> en AWS<\/a>, tres brokers, ZooKeeper reemplazado por KRaft (que ya es el default desde 3.3, por si alguien todav\u00eda est\u00e1 en versiones viejas).<\/p>\n

El setup funcion\u00f3. Los benchmarks de throughput eran buenos. Pero gestionar Kafka en un equipo de cuatro personas donde nadie tiene experiencia profunda de operaciones de Kafka es… complicado. El tuning de configuraci\u00f3n \u2014 num.io.threads<\/code>, log.segment.bytes<\/code>, replica.fetch.max.bytes<\/code> \u2014 requiere entender mucho contexto que simplemente no ten\u00eda.<\/p>\n

Cambi\u00e9 a Redpanda 24.3 despu\u00e9s de<\/a> un post de un ingeniero de Cloudflare que describ\u00eda exactamente mi situaci\u00f3n. Y honestamente, fue la decisi\u00f3n correcta para nuestro tama\u00f1o de equipo. Redpanda es compatible con la API de Kafka al 100% \u2014 mis producers y consumers no cambiaron ni una l\u00ednea \u2014 pero operacionalmente es mucho m\u00e1s simple. No tiene ZooKeeper, no tiene JVM, el binario solo hace una cosa y la hace bien. El lag en nuestro entorno baj\u00f3 de ~15ms a ~3ms para el percentil 99, aunque admito que probablemente eso es m\u00e1s sobre configuraci\u00f3n que sobre la herramienta en s\u00ed.<\/p>\n

Si trabajas en una<\/a> empresa grande con un equipo de plataforma dedicado, Kafka sigue siendo la respuesta correcta. El ecosistema de Confluent, los conectores, el soporte enterprise \u2014 todo eso vale la pena<\/a> si tienes la operaci\u00f3n para manejarlo. Para equipos<\/a> peque\u00f1os sin ese lujo, Redpanda les va a quitar mucho dolor de cabeza.<\/p>\n

La Implementaci\u00f3n Que Realmente<\/a> Uso en Producci\u00f3n<\/h2>\n

El patr\u00f3n que termin\u00e9 adoptando es bastante est\u00e1ndar: transactional outbox para garantizar que los eventos se publiquen consistentemente con los cambios en base de datos<\/a>, y consumers con procesamiento idempotente.<\/p>\n

Ac\u00e1 est\u00e1 la versi\u00f3n simplificada de c\u00f3mo publico eventos desde el servicio de \u00f3rdenes (usamos Node.js con TypeScript):<\/p>\n

\/\/ order-service\/src\/events\/order-event-publisher.ts\nimport { Kafka, Producer, RecordMetadata } from 'kafkajs';\n\n\/\/ Nota: usamos kafkajs 2.2.4 \u2014 la 2.3.x ten\u00eda un bug con reconnects\n\/\/ en conexiones de larga duraci\u00f3n, ver issue #2031 en su GitHub\nconst kafka = new Kafka({\n  clientId: 'order-service',\n  brokers: process.env.KAFKA_BROKERS?.split(',') ?? ['localhost:9092'],\n  retry: {\n    initialRetryTime: 100,\n    retries: 8\n  }\n});\n\ninterface OrderCreatedEvent {\n  orderId: string;\n  userId: string;\n  items: Array<{ productId: string; quantity: number; price: number }>;\n  totalAmount: number;\n  createdAt: string; \/\/ ISO 8601\n}\n\nexport class OrderEventPublisher {\n  private producer: Producer;\n  private connected = false;\n\n  constructor() {\n    this.producer = kafka.producer({\n      \/\/ Esto es<\/a> importante: sin esto, puedes perder mensajes\n      \/\/ si el broker tiene un failover justo cuando publicas\n      allowAutoTopicCreation: false,\n      transactionTimeout: 30000,\n    });\n  }\n\n  async publish(event: OrderCreatedEvent): Promise<RecordMetadata[]> {\n    if (!this.connected) {\n      await this.producer.connect();\n      this.connected = true;\n    }\n\n    return this.producer.send({\n      topic: 'orders.created.v2',\n      messages: [{\n        key: event.orderId,  \/\/ partitioning por orderId \u2014 crucial para ordering\n        value: JSON.stringify(event),\n        headers: {\n          'event-type': 'OrderCreated',\n          'schema-version': '2',\n          'source-service': 'order-service',\n        }\n      }]\n    });\n  }\n}\n<\/code><\/pre>\n
Y del lado del consumidor, en el<\/a> servicio de notificaciones:<\/p>\n
\/\/ notification-service\/src\/consumers\/order-consumer.ts\nimport { Kafka, Consumer, EachMessagePayload } from 'kafkajs';\n\nconst kafka = new Kafka({\n  clientId: 'notification-service',\n  brokers: process.env.KAFKA_BROKERS?.split(',') ?? ['localhost:9092'],\n});\n\nexport class OrderEventConsumer {\n  private consumer: Consumer;\n\n  constructor(private readonly notificationService: NotificationService) {\n    this.consumer = kafka.consumer({\n      groupId: 'notification-service-order-group',\n      \/\/ sessionTimeout m\u00e1s alto que el default (10s) porque nuestro\n      \/\/ procesamiento de notificaciones puede tardar hasta 8 segundos\n      sessionTimeout: 30000,\n    });\n  }\n\n  async start(): Promise<void> {\n    await this.consumer.connect();\n    await this.consumer.subscribe({\n      topic: 'orders.created.v2',\n      fromBeginning: false\n    });\n\n    await this.consumer.run({\n      \/\/ autoCommit: false es non-negotiable si quieres exactly-once sem\u00e1ntica\n      autoCommit: false,\n      eachMessage: async ({ topic, partition, message, heartbeat }: EachMessagePayload) => {\n        const eventData = JSON.parse(message.value?.toString() ?? '{}');\n\n        \/\/ Chequeo de idempotencia antes de procesar\n        const alreadyProcessed = await this.notificationService\n          .isEventProcessed(message.offset, partition);\n\n        if (!alreadyProcessed) {\n          await this.notificationService.sendOrderConfirmation(eventData);\n          await this.notificationService.markEventProcessed(message.offset, partition);\n        }\n\n        \/\/ Commit manual despu\u00e9s de<\/a> procesar exitosamente\n        await this.consumer.commitOffsets([{\n          topic,\n          partition,\n          offset: (BigInt(message.offset) + 1n).toString()\n        }]);\n      }\n    });\n  }\n}\n<\/code><\/pre>\n
Un detalle que me cost\u00f3 un fin de semana entender: el heartbeat<\/code> que viene en eachMessage<\/code> \u2014 si tu procesamiento tarda m\u00e1s que sessionTimeout \/ 2<\/code>, el broker va a asumir que el consumer muri\u00f3 y va a reasignar la partici\u00f3n. En mi caso, una integraci\u00f3n con un proveedor de emails externo que a veces tarda 7-8 segundos casi me destruy\u00f3 en producci\u00f3n<\/a>. Tuve que llamar await heartbeat()<\/code> dentro del procesamiento largo para mantener la sesi\u00f3n viva.<\/p>\n
La Parte Que Nadie<\/a> Menciona: Evoluci\u00f3n de Schemas<\/h2>\n
Aqu\u00ed es donde me quem\u00e9 m\u00e1s. Y donde la mayor\u00eda de los posts de blog que le\u00ed eran demasiado optimistas.<\/p>\n
El problema: publiqu\u00e9 el topic orders.created.v1<\/code> con una estructura. Tres semanas despu\u00e9s, necesitaba agregar un campo. Pens\u00e9: “f\u00e1cil, solo agrego el campo, es backwards compatible.” Y s\u00ed, t\u00e9cnicamente lo es \u2014 mis consumers existentes ignoraban el campo nuevo.<\/p>\n
Hasta que un consumer m\u00e1s viejo que hab\u00eda estado procesando mensajes pausado por un par de horas reinici\u00f3 desde su offset guardado, proces\u00f3 400 mensajes del formato nuevo, y tir\u00f3 excepciones porque no manejaba el campo nuevo correctamente. Esto pas\u00f3 a las<\/a> 2am de un martes y me enter\u00e9 por las alertas de Datadog a las<\/a> 8am.<\/p>\n
El fix correcto \u2014 que ahora implement\u00e9 \u2014 es Avro con Confluent Schema Registry. El registry te fuerza a registrar schemas y valida compatibilidad antes de permitir publicaciones. Pero tiene un costo operacional. Para equipos<\/a> chicos sin la infraestructura<\/a> de Confluent, lo m\u00ednimo que recomendar\u00eda es:<\/p>\n
    \n
  1. Versionar los topics (orders.created.v1<\/code>, orders.created.v2<\/code>) en lugar de evolucionar el schema in-place<\/li>\n
  2. Incluir siempre un header schema-version<\/code> (como en mi c\u00f3digo arriba)<\/li>\n
  3. Mantener consumers con handling expl\u00edcito por versi\u00f3n durante el per\u00edodo de transici\u00f3n<\/li>\n<\/ol>\n
    No es tan elegante como el registry, pero es mucho m\u00e1s simple de operar. Y evita el tipo de sorpresa que me dio ese martes.<\/p>\n
    Dicho esto, si tu organizaci\u00f3n ya usa Confluent Platform, el Schema Registry vale la pena<\/a> desde el d\u00eda uno. No seas como yo y lo agregues despu\u00e9s de<\/a> tener un incidente.<\/p>\n
    Qu\u00e9 Patrones Realmente Funcionan y Cu\u00e1les Son Over-Engineering<\/h2>\n
    Despu\u00e9s de unos meses en<\/a> producci\u00f3n<\/a>, tengo opiniones m\u00e1s definidas sobre qu\u00e9 usar y qu\u00e9<\/a> no.<\/p>\n
    Event Sourcing completo:<\/strong> probablemente no lo necesitas. Es uno de esos patterns que lees en los blogs de arquitectura y parece que deber\u00edas usar siempre. En mi experiencia con un equipo chico, la complejidad de mantener un event log como fuente de verdad<\/a> y reconstruir estado a partir de events hist\u00f3ricos crea m\u00e1s problemas de los que resuelve, a menos que tengas un requerimiento muy espec\u00edfico de auditor\u00eda o replay. Lo estuve considerando para el servicio de inventario y decid\u00ed no hacerlo. No me arrepent\u00ed.<\/p>\n
    CQRS combinado con event streaming<\/a>:<\/strong> esto s\u00ed funciona bien si tienes casos de uso de lectura y escritura con requisitos muy diferentes. Usamos una versi\u00f3n simplificada: los writes van a nuestra base de datos<\/a> transaccional (PostgreSQL), y los events que publicamos mantienen sincronizado un \u00edndice de Elasticsearch para b\u00fasqueda. No es CQRS puro, pero resuelve el problema real.<\/p>\n
    Saga pattern para transacciones distribuidas:<\/strong> necesario si tienes operaciones que cruzan m\u00faltiples servicios y necesitas rollback coordinado. Implement\u00e9 esto para el flow de checkout \u2014 si el pago falla, el inventario reservado tiene que liberarse. La implementaci\u00f3n con compensating transactions y un saga orchestrator (usamos Temporal para esto, que tiene muy buena integraci\u00f3n con Kafka) funciona bien, pero agregas complejidad operacional. Mi recomendaci\u00f3n: si puedes dise\u00f1ar el sistema para que las operaciones sean idempotentes y eventualmente consistentes sin necesitar rollback s\u00edncrono, hazlo. El saga pattern es el \u00faltimo recurso, no el primero.<\/p>\n
    Lo Que Har\u00eda Distinto Si Empezara de Nuevo<\/h2>\n
    \u00bfQu\u00e9 recomendar\u00eda concretamente? Si est\u00e1s en un equipo de menos de 8 ingenieros y no tienes un equipo de plataforma dedicado, empieza con Redpanda en lugar de Kafka \u2014 la paridad de API es real y te va a ahorrar semanas de tuning operacional.<\/p>\n
    Usa topics versionados desde el d\u00eda uno, no intentes evolucionar schemas in-place. Implementa idempotencia en tus consumers antes de preocuparte por cualquier otra cosa \u2014 es la garant\u00eda que m\u00e1s necesitas en la pr\u00e1ctica. Y no migres todo de golpe: identifica los flujos donde el desacoplamiento temporal te da m\u00e1s valor (generalmente los que tienen m\u00e1s dependencias s\u00edncronas en cadena) y empieza por ah\u00ed.<\/p>\n
    Yo no estoy 100% seguro de que este approach escale m\u00e1s all\u00e1 de 20-30 servicios sin revisitar algunas decisiones, pero para el tama\u00f1o donde estamos ahora, es lo<\/a> m\u00e1s sensato que hemos hecho en arquitectura en dos a\u00f1os.<\/p>\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    Hace unos diez meses, un servicio de notificaciones llam\u00f3 a un servicio de inventario, que llam\u00f3 a un servicio de precios, que estaba ca\u00eddo por un deploy m<\/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-170","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/170","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=170"}],"version-history":[{"count":18,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/170\/revisions"}],"predecessor-version":[{"id":654,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/170\/revisions\/654"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}