Arquitectura Orientada a Eventos en 2026: Cómo Reemplazar REST entre Microservicios con un Enfoque más Escalable

Un viernes por la tarde, tres usuarios reportando errores extraños en checkout, y cuatro ventanas de logs abiertas en paralelo intentando reconstruir una cadena de llamadas que ya había colapsado. Ese tipo de momento no se olvida — y para un equipo de cuatro ingenieros manejando una plataforma de e-commerce con seis servicios independientes, fue el punto de quiebre que llevó a repensar completamente cómo los servicios se hablan entre sí.

Por qué el acoplamiento temporal es el verdadero enemigo

La trampa más común al diseñar microservicios es asumir que el problema con las llamadas síncronas es rendimiento. No lo es. El problema es que cuando el Servicio A hace un HTTP request al Servicio B, en ese instante exacto ambos tienen que estar vivos, responder dentro del timeout, y coincidir en el contrato de la API. Si cualquiera de esas condiciones falla, el error sube por la cadena.

En un sistema de 8 a 10 servicios — inventario, órdenes, notificaciones, pagos, búsqueda, usuarios — esas cadenas de dependencia se vuelven imposibles de razonar. El circuit breaker pattern, implementado con Resilience4j en servicios Spring Boot, mitiga el problema pero no lo elimina. El resultado son cascadas de fallbacks que generan estados inconsistentes difíciles de reproducir.

El event streaming resuelve algo distinto: el productor publica un evento y no le importa quién lo consume ni cuándo. El consumidor procesa cuando puede. El desacoplamiento temporal no es un side effect — es el punto central del modelo.

Kafka 3.8 vs Redpanda 24.3: lo que el tamaño del equipo cambia todo

La primera decisión fue Apache Kafka 3.8. Documentación sólida, ecosistema maduro, Confluent Schema Registry disponible. Dos semanas configurando el cluster en staging — Kubernetes en AWS, tres brokers, KRaft como reemplazo de ZooKeeper (default desde la versión 3.3). El setup funcionó y los benchmarks de throughput eran aceptables.

El problema no era técnico. Era operacional. Gestionar Kafka en un equipo pequeño sin experiencia profunda en sus operaciones requiere entender un volumen de configuración — num.io.threads, log.segment.bytes, replica.fetch.max.bytes — que simplemente no estaba disponible en ese contexto.

El cambio a Redpanda 24.3 vino después de leer sobre una situación idéntica documentada por un ingeniero de Cloudflare. La compatibilidad con la API de Kafka es completa — producers y consumers no requirieron ningún cambio de código — pero la carga operacional es significativamente menor. Sin ZooKeeper, sin JVM, un binario que hace una sola cosa. La latencia en el percentil 99 bajó de aproximadamente 15ms a 3ms, aunque parte de esa mejora probablemente se explica por diferencias de configuración más que por la herramienta en sí.

La distinción práctica es clara: para empresas con un equipo de plataforma dedicado, Kafka sigue siendo la respuesta correcta. El ecosistema de Confluent, los conectores, el soporte enterprise — todo eso tiene valor real si existe la capacidad operacional para aprovecharlo. Para equipos pequeños sin ese lujo, Redpanda reduce considerablemente la fricción.

El patrón en producción: transactional outbox e idempotencia

El patrón adoptado combina transactional outbox para garantizar que los eventos se publiquen de forma consistente con los cambios en base de datos, y consumers con procesamiento idempotente. La implementación en el servicio de órdenes usa Node.js con TypeScript y kafkajs 2.2.4 — la versión 2.3.x tenía un bug con reconnects en conexiones de larga duración (issue #2031 en el repositorio oficial).

// order-service/src/events/order-event-publisher.ts
import { Kafka, Producer, RecordMetadata } from 'kafkajs';
// Nota: usamos kafkajs 2.2.4 — la 2.3.x tenía un bug con reconnects
// en conexiones de larga duración, ver issue #2031 en su GitHub
const kafka = new Kafka({
clientId: 'order-service',
brokers: process.env.KAFKA_BROKERS?.split(',') ?? ['localhost:9092'],
retry: {
initialRetryTime: 100,
retries: 8
}
});
interface OrderCreatedEvent {
orderId: string;
userId: string;
items: Array<{ productId: string; quantity: number; price: number }>;
totalAmount: number;
createdAt: string; // ISO 8601
}
export class OrderEventPublisher {
private producer: Producer;
private connected = false;
constructor() {
this.producer = kafka.producer({
// Sin esto, se pueden perder mensajes si el broker
// tiene un failover justo en el momento de publicar
allowAutoTopicCreation: false,
transactionTimeout: 30000,
});
}
async publish(event: OrderCreatedEvent): Promise<RecordMetadata[]> {
if (!this.connected) {
await this.producer.connect();
this.connected = true;
}
return this.producer.send({
topic: 'orders.created.v2',
messages: [{
key: event.orderId, // partitioning por orderId — crucial para ordering
value: JSON.stringify(event),
headers: {
'event-type': 'OrderCreated',
'schema-version': '2',
'source-service': 'order-service',
}
}]
});
}
}

Dos detalles de implementación que no son opcionales: allowAutoTopicCreation: false evita pérdida de mensajes durante failovers del broker, y el partitioning por orderId como key garantiza el ordering dentro de cada orden. El versionado explícito del topic — orders.created.v2 — junto con el header schema-version permite evolucionar el contrato sin romper consumers existentes.

Lo que este cambio revela sobre cómo escalan los equipos pequeños

Hay algo más interesante que la elección técnica en sí. La migración de REST síncrono a event streaming en un equipo de cuatro personas no fue principalmente una decisión de arquitectura — fue una decisión de operabilidad. La pregunta no era "¿qué sistema es más correcto?" sino "¿qué sistema podemos mantener sin que nos consuma?"

Eso cambia el análisis de herramientas por completo. Kafka es técnicamente superior en muchos aspectos para cargas de trabajo a escala, pero "técnicamente superior" no tiene valor si el equipo no puede operar la herramienta de forma sostenible. Redpanda gana en ese contexto no porque sea mejor en abstracto, sino porque reduce la carga cognitiva operacional a un nivel manejable para un equipo pequeño.

El mismo principio aplica al patrón de outbox transaccional. No es el enfoque más simple de implementar inicialmente, pero elimina una clase entera de bugs relacionados con consistencia entre la base de datos y el broker — bugs que en producción son exactamente el tipo que aparece un viernes por la tarde y tarda horas en diagnosticar.

Diez meses después de ese incidente de checkout, el servicio de notificaciones puede estar caído durante horas y el flujo de órdenes sigue funcionando sin errores visibles para el usuario. Los eventos se acumulan, el consumer los procesa cuando vuelve, y el sistema converge solo. Esa resiliencia no vino de agregar más circuit breakers — vino de eliminar la dependencia de tiempo de ejecución desde el principio.

Building distributed systems that hold up under real-world pressure is less about choosing the right tools and more about the decisions made before writing a single line of code. Two principles, in particular, tend to separate architectures that age well from those that become expensive problems: schema versioning and consumer idempotency.

Version Your Schemas From Day One

The temptation to evolve schemas in-place is understandable — it feels faster, leaner, and avoids the overhead of version management early on. But that shortcut accumulates debt silently. By the time a team realizes the schema has drifted into something unmaintainable, the cost of untangling it is orders of magnitude higher than if versioning had been built into the foundation. The recommendation here is unambiguous: versioned topics from the start, no exceptions.

This is not a theoretical concern. In practice, distributed systems that skip this step tend to hit a wall during the first major feature rollout or service expansion, when producers and consumers inevitably fall out of sync and backward compatibility becomes an emergency retrofit rather than a planned feature.

Idempotency Is the Guarantee That Actually Matters

Of all the reliability patterns available to engineers working with event-driven architectures, idempotent consumers deserve priority above almost everything else. The reasoning is straightforward: in any system where messages can be redelivered — and they will be — a consumer that processes the same event twice without side effects is far more resilient than one relying on delivery guarantees alone.

This is the guarantee that holds up under the conditions real systems actually face: network partitions, broker restarts, consumer group rebalances. Focusing on idempotency before optimizing for throughput, latency, or fault isolation means building on stable ground rather than stacking complexity on an uncertain base.

Why Incremental Migration Beats a Big-Bang Approach

When introducing event-driven patterns into an existing architecture, the instinct to migrate everything at once is almost always a mistake. The more defensible strategy is to identify the flows where temporal decoupling delivers the most immediate value — typically those carrying the heaviest chains of synchronous dependencies — and start there.

Synchronous dependency chains are where latency compounds and failure propagates most aggressively. Replacing those specific paths with asynchronous event flows reduces cascading risk while generating early evidence of what the new architecture actually costs to operate. That evidence is worth more than any theoretical model, and it gives teams the information needed to make smarter decisions about what to migrate next.

What This Means for Teams Scaling Beyond a Handful of Services

There is an honest caveat worth sitting with: this approach has not been stress-tested beyond roughly 20 to 30 services. Whether the same decisions hold at larger scale — or whether some of them need to be revisited as complexity grows — remains an open question. That kind of intellectual honesty about architectural limits is itself a signal of mature engineering thinking.

For organizations operating at that size range, however, the combination of versioned schemas, idempotent consumers, and targeted incremental migration represents a coherent and pragmatic foundation. The claim is not that it solves every distributed systems problem. The claim is that, for the scope where it has been applied, it is the most sensible architectural work done in two years — and in a domain where good judgment is often harder to find than good technology, that is a meaningful endorsement.

The broader lesson is that event-driven architecture rewards deliberate, staged adoption far more than it rewards ambition. Teams that resist the urge to solve everything at once, and instead build reliable primitives first, tend to end up with systems that are actually easier to reason about — not harder.