De lotes a eventos: cuando los datos no pueden esperar

### El problema: el mundo no espera a tu cron de las 6AM

Imagina que llevas meses trabajando en una empresa de e-commerce. Tu pipeline es impecable: cada noche a las 2AM un DAG de Airflow extrae los pedidos del día, los limpia, los carga en el warehouse y a las 6AM el equipo de negocio tiene sus dashboards actualizados. Estás orgulloso. Y entonces llega el Product Manager con una sonrisa que ya conoces: "Oye, necesitamos que cuando un usuario haga un pedido, se actualice el inventario EN TIEMPO REAL, se envíe el email de confirmación Y se notifique al almacén para que empiece a preparar el envío. Todo al instante. No mañana a las 6AM."

Tu pipeline batch, por muy bien diseñado que esté, no puede resolver esto. No es un problema de optimización ni de frecuencia de ejecución. Es un cambio FILOSÓFICO en cómo piensas sobre el flujo de datos. Bienvenido al mundo de los eventos.

### La analogía del restaurante

Para entender la diferencia entre batch y eventos, piensa en un restaurante. En el modelo BATCH, el camarero espera a que todos los comensales de todas las mesas hayan decidido qué quieren. Solo entonces lleva TODOS los pedidos a la cocina de una sola vez. La cocina recibe 47 comandas a las 21:00 y tiene que procesarlas todas juntas. Los primeros clientes que pidieron llevan 45 minutos esperando. El cocinero está colapsado.

En el modelo EVENT-DRIVEN, cada vez que un comensal decide su plato, el camarero lleva ESA comanda a la cocina INMEDIATAMENTE. La cocina recibe un flujo constante de pedidos y los va procesando según llegan. El primer cliente que pidió recibe su plato en 15 minutos. El cocinero tiene una carga distribuida en el tiempo. Nadie espera innecesariamente.

Eso es exactamente lo que hacemos con los sistemas de eventos: en lugar de acumular datos y procesarlos todos juntos cada X horas, reaccionamos a cada dato EN EL MOMENTO en que se produce. Un pedido nuevo es un EVENTO. Un pago confirmado es un EVENTO. Un producto que se queda sin stock es un EVENTO. Y cada evento dispara acciones inmediatas.

### Qué es un evento exactamente

Un evento es un HECHO INMUTABLE que ocurrió en un momento concreto. No es una instrucción ("haz esto"), es una notificación ("esto pasó"). El evento describe lo que pasó; quién escucha ese evento y qué hace con él es otra decisión completamente separada. El sistema que genera el pedido no sabe ni le importa quién va a reaccionar. Solo dice "hey, pasó esto". El productor del evento está DESACOPLADO de los consumidores.

1# Anatomía de un evento típico
2evento_pedido = {
3    "source": "servicio-pedidos",
4    "detail-type": "PedidoCreado",
5    "time": "2024-03-15T14:23:07Z",
6    "detail": {
7        "pedido_id": "ORD-1337",
8        "cliente_id": "CLI-42",
9        "items": [
10            {"producto": "Teclado mecánico", "cantidad": 1, "precio": 89.99},
11            {"producto": "Cable USB-C", "cantidad": 2, "precio": 12.50}
12        ],
13        "total": 114.99,
14        "metodo_pago": "tarjeta"
15    }
16}
17# El evento dice QUÉ PASÓ, no qué hacer con ello.
18# Quien escuche decide cómo reaccionar.

### Historia: cómo llegamos aquí

En los años 2000, todo era batch. Los bancos procesaban transacciones por la noche. Los e-commerce actualizaban precios una vez al día. Pero entonces llegaron los smartphones, las apps en tiempo real, los mercados globales 24/7. Amazon empezó a hacer recomendaciones EN TIEMPO REAL. Uber necesitaba saber la posición de cada conductor CADA SEGUNDO. Netflix necesitaba registrar cada clic para alimentar su algoritmo AL INSTANTE. El batch no escalaba a ese mundo.

LinkedIn creó Kafka en 2011 porque necesitaba procesar miles de millones de eventos diarios — actividad de usuarios, métricas de rendimiento, logs de aplicaciones. Amazon creó SQS en 2004 como uno de los primeros servicios de AWS. EventBridge llegó en 2019 como evolución: un bus de eventos serverless que conecta servicios sin que tú gestiones infraestructura. Cada una resolvió un problema concreto de su época.

### Productores, consumidores y brokers

Todo sistema de eventos tiene tres actores: el PRODUCTOR genera el evento (la app que registra un pedido). El CONSUMIDOR reacciona al evento (el servicio de emails, el de inventario). Y en medio está el BROKER: la infraestructura que recibe eventos y los entrega a los consumidores. El broker desacopla productores de consumidores — añadir un consumidor nuevo es CERO cambios en el productor.

• ▹PRODUCTOR: genera eventos — "PedidoCreado", "PagoConfirmado", "StockBajo"
• ▹BROKER: recibe, almacena y distribuye eventos a quien esté suscrito
• ▹CONSUMIDOR: escucha eventos y reacciona — envía email, actualiza DB, lanza alerta

### Las tres tecnologías que vas a aprender

1. 01.Amazon SQS — Cola punto a punto. Simple, serverless, económica. Las colas estándar son at-least-once; las FIFO garantizan orden y deduplicación (exactly-once en la cola). Como un buzón de correos.
2. 02.Amazon EventBridge — Bus de eventos con ROUTING inteligente. Decide A QUIÉN entregar según reglas. Como la centralita de un hotel.
3. 03.Apache Kafka — Autopista de datos de alta velocidad. Millones de mensajes/segundo, múltiples consumidores, capacidad de REPLAY. Como una cinta transportadora industrial.

### Garantías de entrega: at-least-once vs exactly-once

Un tema filosófico fundamental en sistemas distribuidos: ¿cuántas veces se entrega un mensaje? AT-MOST-ONCE: puede perderse pero nunca se duplica. AT-LEAST-ONCE: se entrega seguro pero PUEDE llegar duplicado (modo por defecto del consumidor de SQS estándar y del consumidor de Kafka con auto-commit). EXACTLY-ONCE: existe de verdad desde 2017 — Kafka lo implementa en el productor con idempotencia (enable.idempotence, activado por defecto desde Kafka 3.0) y en el consumidor con transacciones. SQS lo ofrece en colas FIFO con una ventana de deduplicación de 5 minutos. En la práctica, la inmensa mayoría de los sistemas usan at-least-once con consumidores IDEMPOTENTES que saben manejar duplicados sin causar daño, porque la idempotencia es más barata que las transacciones distribuidas y funciona igual de bien.

1# Consumidor IDEMPOTENTE: procesar el mismo evento 2 veces no causa daño
2def procesar_pedido(evento):
3    pedido_id = evento["detail"]["pedido_id"]
4    
5    # Check de idempotencia: ¿ya procesé este evento?
6    if ya_procesado(pedido_id):
7        print(f"Evento {pedido_id} ya procesado, ignorando duplicado")
8        return
9    
10    # Procesamiento real
11    actualizar_inventario(evento["detail"]["items"])
12    enviar_email_confirmacion(evento["detail"]["cliente_id"])
13    
14    # Marcar como procesado DESPUÉS de todo el trabajo
15    marcar_procesado(pedido_id)

### Lo que viene en esta skill

En las próximas lecciones vamos a ensuciarnos las manos. Primero levantaremos EventBridge y SQS en local con LocalStack (lección 2). Construirás tu primer flujo event-driven completo (lección 3). Aprenderás patrones avanzados: fan-out, dead letter queues y reintentos (lección 4). Después instalaremos Kafka con Docker (lección 5) y dedicaremos DOS lecciones completas a dominarlo: consumer groups, offsets, exactly-once (lección 6) y streaming real con transformaciones (lección 7). Finalmente, compararemos las tres tecnologías con un framework de decisión para tu arquitectura (lección 8).