Architecture / Kafka

Arquitectura Orientada a Eventos y Servicios con Apache Kafka

Entiende cómo los sistemas modernos se comunican sin depender el uno del otro — con analogías simples, diagramas y código .NET real

Felipe Araujo Pacheco Enero 2026 12 min de lectura

Imagina que tienes una tienda online. Un cliente hace un pedido. ¿Qué tiene que pasar después? Enviar email de confirmación, descontar del inventario, notificar al almacén, actualizar puntos de fidelidad, generar el cobro... Si todo eso tuviera que hacerse uno a uno, en secuencia, tu sistema sería una pesadilla.

Ese es exactamente el problema que resuelve la Arquitectura Orientada a Eventos. Y Apache Kafka es una de las herramientas más potentes para implementarla.

1. Tradicional vs Orientada a Eventos: ¿Cuál es la diferencia?

En una arquitectura tradicional (síncrona), los servicios se llaman directamente entre ellos. El Servicio A llama al Servicio B, espera respuesta, luego llama al C, espera, y así sucesivamente.

Arquitectura Tradicional — Llamadas directas (fuertemente acoplada)
Servicio Pedido espera... Servicio Email espera... Servicio Inventario espera... Servicio Almacén ❌ Si uno falla, todo falla. Cada uno espera al anterior.

En una arquitectura orientada a eventos, los servicios no se llaman entre sí. En cambio, publican eventos a un canal central (como Kafka) y otros servicios escuchan esos eventos de forma independiente.

Arquitectura Orientada a Eventos — Desacoplada mediante Kafka
Servicio Pedido Productor evento Apache Kafka Topic: "pedido-creado" particiones Servicio Email Servicio Inventario Servicio Almacén Consumidores ✅ Cada servicio reacciona independientemente. Sin acoplamiento.

2. ¿Qué es Apache Kafka?

Kafka es una plataforma de mensajería distribuida. Imagínala como una oficina de correos superpotente, extremadamente rápida y confiable. Los servicios dejan mensajes ahí, y otros servicios los recogen cuando están listos.

📦 Dato real

LinkedIn creó Kafka en 2011 para manejar 1 billón de eventos por día. Hoy lo usan Netflix, Uber, Airbnb y miles de empresas. Puede manejar millones de mensajes por segundo.

3. Conceptos clave (en lenguaje sencillo)

Productor
Servicio que envía (publica) mensajes a Kafka. Como alguien que deposita una carta en el buzón.
Consumidor
Servicio que lee mensajes de Kafka. Como alguien que abre el buzón y lee las cartas.
Topic
Canal nombrado donde se agrupan mensajes del mismo tipo. Ejemplo: "pedidos", "pagos", "usuarios". Como una carpeta con etiqueta.
Partición
Un topic se divide en particiones para procesar más mensajes en paralelo. Como tener varias cajas en el supermercado.
Broker
Servidor de Kafka que almacena los mensajes. Puede haber varios para redundancia. Como el edificio de la oficina de correos.
Consumer Group
Grupo de consumidores que trabajan juntos para leer un topic. Cada mensaje va a solo un miembro del grupo.
Topic con 3 Particiones — Los mensajes se distribuyen
Productor Servicio Pedidos Topic: "pedido-creado" P0: M1 M4 M7 P1: M2 M5 M8 P2: M3 M6 M9 Consumer Group Svc. Email Svc. Inventario

4. Kafka en .NET — Productor

Instala el cliente oficial de Kafka para .NET:

NuGet
dotnet add package Confluent.Kafka

Un Productor envía eventos a un topic de Kafka. En nuestro ejemplo, el servicio de pedidos publica un evento cada vez que se crea uno:

C# — Kafka Productor
public class OrderProducer
{
    private readonly IProducer<string, string> _producer;

    public OrderProducer()
    {
        var config = new ProducerConfig
        {
            BootstrapServers = "localhost:9092" // dirección del servidor Kafka
        };
        _producer = new ProducerBuilder<string, string>(config).Build();
    }

    public async Task PublishOrderCreatedAsync(string orderId)
    {
        var message = new Message<string, string>
        {
            Key   = orderId,              // agrupa mensajes del mismo pedido
            Value = $"{{\"orderId\":\"{orderId}\",\"status\":\"created\"}}"
        };

        await _producer.ProduceAsync("pedido-creado", message);

        Console.WriteLine($"✅ Evento publicado: pedido {orderId}");
    }
}

5. Kafka en .NET — Consumidor

Un Consumidor escucha el topic y reacciona a cada evento. Aquí el servicio de email escucha y envía una confirmación:

C# — Kafka Consumidor
public class EmailConsumer : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        var config = new ConsumerConfig
        {
            BootstrapServers = "localhost:9092",
            GroupId          = "email-service-group", // ID del grupo
            AutoOffsetReset  = AutoOffsetReset.Earliest
        };

        using var consumer = new ConsumerBuilder<string, string>(config).Build();
        consumer.Subscribe("pedido-creado"); // suscribirse al topic

        while (!ct.IsCancellationRequested)
        {
            var result = consumer.Consume(ct); // espera el siguiente mensaje

            Console.WriteLine($"📧 Enviando email para pedido: {result.Message.Key}");

            await SendConfirmationEmailAsync(result.Message.Value);
        }
    }
}
✅ Punto clave

El servicio de inventario puede tener su propio consumidor con GroupId = "inventory-service-group" y también recibirá todos los eventos del topic, de forma independiente al de email.

6. ¿Cuándo usar Kafka?

Usa Kafka cuando... No uses Kafka cuando...
Necesitas procesamiento de eventos en tiempo real Tu app es un CRUD sencillo
Varios servicios necesitan reaccionar al mismo evento Necesitas respuesta síncrona inmediata
Quieres guardar historial de eventos (event sourcing) Tienes solo 1 o 2 servicios
Alto volumen: miles de mensajes por segundo El overhead de infraestructura es excesivo para tu proyecto
Necesitas tolerancia a fallos y replay de mensajes Una cola simple (Azure Service Bus, RabbitMQ) resuelve el problema

7. Ejemplo real: Flujo de pedido en e-commerce

Flujo completo de eventos — Del pedido a la entrega
Cliente hace pedido Kafka "pedido-creado" "pago-procesado" Pagos Stripe / Redsys Inventario descontar stock Notificaciones email / SMS Kafka "pago-ok" "pedido-enviado" Almacén envío ⚡ Todo en milisegundos, sin que ningún servicio espere al otro

8. Kafka vs otras colas

Apache Kafka Azure Service Bus RabbitMQ
Volumen Millones/seg Miles/seg Miles/seg
Retención Días / semanas Hasta consumir Hasta consumir
Replay ✅ Sí ❌ No ❌ No
Ideal para Streaming, big data, event sourcing Servicios Azure, mensajería simple Tareas, routing complejo
Complejidad Alta (ZooKeeper / KRaft) Baja (managed) Media
💡 Consejo práctico

Si estás en Azure y tu volumen es moderado, Azure Service Bus es más sencillo y no requiere infraestructura. Usa Kafka cuando necesites alto throughput, replay de eventos, o ya tengas un entorno multi-cloud.

Resumen

Lo que debes recordar 🧠

¿Preguntas o quieres que profundice — Kafka Streams, KSQL o event sourcing con .NET? Escríbeme a felipe@faraujop.com o por WhatsApp.

Felipe Araujo Pacheco
Felipe Araujo Pacheco
Tech Lead & Engineering Manager con 15+ años en .NET, cloud y arquitectura de microservicios. Actualmente en Eni Plenitude Iberia, Santander.
Ver portfolio →
Volver al blog