Kafka vs SQS vs EventBridge: el árbol de decisión definitivo

### La pregunta que todo junior hace mal

"¿Cuál es mejor: Kafka, SQS o EventBridge?" Esta pregunta no tiene sentido. Es como preguntar "¿qué es mejor: un coche, una bicicleta o un avión?" Depende de a dónde vas, cuánta prisa tienes, cuánto equipaje llevas y cuánto puedes gastar. Cada tecnología resuelve un PROBLEMA DIFERENTE y tiene trade-offs diferentes. La respuesta correcta siempre es "depende" — pero aquí vamos a construir un framework para decidir CON CRITERIO.

He visto equipos elegir Kafka para 100 mensajes/día (overkill absurdo: como usar un camión de 18 ruedas para ir al supermercado) y equipos usando SQS para streaming de 1M eventos/segundo (un buzón de correos no es una autopista). La tecnología correcta depende de TUS requisitos reales, no de la moda.

### Resumen de cada tecnología

SQS: la más SIMPLE. Una cola punto a punto, completamente serverless. Un productor, un consumidor (o pool de consumidores). El mensaje se consume y desaparece. Cero infraestructura que gestionar. Ideal para desacoplamiento básico entre microservicios. Cubre la mayoría de los casos de uso en empresas pequeñas/medianas.

EventBridge: un ROUTER inteligente de eventos. Recibe un evento y decide a quién entregarlo basándose en reglas de contenido. Serverless total. Ideal cuando tienes múltiples productores, múltiples consumidores y necesitas routing flexible sin gestionar infraestructura. El "conector universal" del ecosistema AWS.

Kafka: una PLATAFORMA de streaming. Log distribuido persistente, múltiples consumidores leen independientemente, replay, alta throughput (millones/segundo), consumer groups. Requiere gestión de infraestructura (o Confluent Cloud). Ideal para streaming masivo, event sourcing y cuando necesitas REPLAY de datos históricos.

### Comparativa técnica detallada

• ▹THROUGHPUT: SQS estándar escalado prácticamente ilimitado, FIFO 300 TPS/acción sin lotes (3.000 con lotes, hasta 70.000 en high throughput mode) | EventBridge 600-10.000 eventos/s según región (ajustable) | Kafka millones/s
• ▹LATENCIA: SQS ~10-50ms | EventBridge ~50-100ms | Kafka ~2-5ms
• ▹PERSISTENCIA: SQS 4-14 días (se borra al consumir) | EventBridge 24h archivo | Kafka días/semanas/infinito (configurable)
• ▹REPLAY: SQS NO | EventBridge limitado (archive) | Kafka SÍ (nativo, rebobinar offsets)
• ▹ORDEN: SQS FIFO sí (con throughput limitado) | EventBridge no garantizado | Kafka SÍ dentro de partición
• ▹GESTIÓN: SQS serverless total | EventBridge serverless total | Kafka requiere cluster (o Confluent Cloud)
• ▹COSTE bajo volumen: SQS centavos | EventBridge centavos | Kafka $$ (mínimo 3 brokers)
• ▹MÚLTIPLES CONSUMIDORES: SQS NO (un msg → un consumidor) | EventBridge SÍ (reglas → targets) | Kafka SÍ (consumer groups independientes)

### Casos de uso ideales para cada una

SQS brilla cuando: necesitas desacoplar dos servicios de forma simple, procesar tareas en background (enviar emails, generar PDFs, resize de imágenes), o implementar un worker pattern (N workers compitiendo por tareas de una cola). Si tu caso es "servicio A necesita decirle algo a servicio B sin esperar respuesta", SQS es tu herramienta.

EventBridge brilla cuando: tienes un evento y múltiples sistemas necesitan reaccionar, pero de formas diferentes. El routing por contenido es su superpoder: "si el pedido es de más de 500€ Y el cliente es nuevo, enviar a soporte VIP Y a marketing". Es perfecto para orquestar microservicios con reglas de negocio complejas sin acoplarlos.

Kafka brilla cuando: necesitas alto volumen (>10K msg/s sostenido), replay de datos (reprocesar historial), múltiples consumidores independientes leyendo el mismo flujo, event sourcing (el log ES tu fuente de verdad) o streaming con transformaciones y agregaciones. Si tienes un "firehose" de datos que múltiples equipos necesitan consumir, Kafka es la respuesta.

### Los anti-patrones: cuándo NO usar cada una

• ▹NO uses SQS si necesitas que múltiples servicios lean el mismo mensaje (es 1:1, no pub/sub). Usa SNS+SQS o EventBridge.
• ▹NO uses EventBridge para alto volumen sostenido (>10K/s). Sus límites son bajos para streaming masivo.
• ▹NO uses Kafka para 100 mensajes al día. La complejidad operacional no justifica el beneficio. SQS hace lo mismo en 5 minutos sin gestionar nada.
• ▹NO uses Kafka sin equipo DevOps dedicado (o usa Confluent Cloud). Un cluster Kafka mal gestionado es una bomba de relojería.
• ▹NO uses SQS FIFO si necesitas más de 3.000 msg/s sin lotes (o más de 70.000 con high throughput mode). Por encima de eso, necesitas Kafka o particionar en varias colas.

### El framework de decisión de 5 preguntas

Antes de elegir, responde estas 5 preguntas con tu equipo. Las respuestas te llevan a la tecnología correcta en 2 minutos:

1. 01.¿Necesitas REPLAY (releer datos históricos)? → SÍ: Kafka. NO: sigue preguntando.
2. 02.¿Volumen sostenido > 10K mensajes/segundo? → SÍ: Kafka. NO: sigue preguntando.
3. 03.¿Múltiples consumidores independientes para el mismo evento? → SÍ y con routing: EventBridge. SÍ y sin routing: SNS+SQS.
4. 04.¿Routing inteligente por contenido del evento? → SÍ: EventBridge. NO: sigue.
5. 05.¿Solo desacoplar punto a punto? → SQS. Simple, barato, sin gestión.

### La realidad: sistemas híbridos

En producción real, la mayoría de arquitecturas usan MÚLTIPLES tecnologías juntas. No es raro ver: Kafka para el stream de datos principal (actividad de usuario, eventos de negocio), EventBridge para orquestación entre microservicios AWS (bajo volumen pero alta flexibilidad), y SQS como buffer entre servicios que necesitan desacoplamiento simple.

1# Ejemplo de arquitectura híbrida real:
2#
3# [App mobile] → Kafka (topic: user-activity)
4#     ├── Consumer Group A: Analytics pipeline (PySpark)
5#     ├── Consumer Group B: Recommendation engine (ML)
6#     └── Consumer Group C: Writes to EventBridge
7#
8# [EventBridge]
9#     ├── Rule: "PedidoCreado" → SQS: process-orders
10#     ├── Rule: "PagoConfirmado" → SQS: send-emails
11#     └── Rule: "StockBajo" → Lambda: alert-ops
12#
13# [SQS: process-orders]
14#     └── Worker fleet (3 instancias) → PostgreSQL
15#
16# Kafka = firehose de alto volumen
17# EventBridge = routing inteligente a bajo volumen
18# SQS = procesamiento de tareas desacoplado
19
20arquitectura = {
21    "kafka_topics": ["user-activity", "transactions", "logs"],
22    "eventbridge_rules": ["pedidos", "pagos", "alertas"],
23    "sqs_queues": ["process-orders", "send-emails", "resize-images"],
24    "principio": "Cada tecnología donde brilla, no una para todo.",
25}

### Coste: la variable que nadie menciona

SQS cobra por mensaje (~$0.40 por millón). A bajo volumen, es centavos. EventBridge cobra por evento (~$1.00 por millón). A bajo volumen, centavos también. Kafka auto-gestionado son servidores 24/7: mínimo 3 brokers en producción. A 1.000 msgs/día, Kafka cuesta $500/mes y SQS cuesta $0.001. A 1M msgs/hora, Kafka sigue costando los mismos $500 y SQS cuesta $400/mes. El crossover de coste está alrededor de 50-100K msgs/hora.

Confluent Cloud (Kafka gestionado) cobra por GB transferido y almacenado. Es más barato que auto-gestionar si no tienes equipo DevOps Kafka dedicado. MSK (Amazon Managed Streaming) es otra opción gestionada. Evalúa siempre: ¿el coste de la herramienta incluye el coste del EQUIPO que la gestiona?

### Resumen ejecutivo (para la reunión del lunes)

• ▹SQS: "Necesitamos una cola simple, sin gestión, para desacoplar servicios. Es lo más sencillo que resuelve el problema."
• ▹EventBridge: "Necesitamos routing inteligente de eventos a múltiples destinos con reglas de contenido, sin infraestructura."
• ▹Kafka: "Necesitamos un firehose de datos con replay, múltiples consumidores y alto volumen. Aceptamos la complejidad operacional."

### Cierre de la Skill: lo que ahora sabes

Felicidades. Has recorrido todo el espectro de la mensajería y los eventos: desde el concepto de evento y la filosofía event-driven, pasando por EventBridge y SQS con LocalStack, patrones avanzados de producción, hasta Kafka en profundidad con consumer groups, offsets, garantías de entrega y streaming real. Ya puedes tomar decisiones INFORMADAS sobre arquitectura de eventos. Eso te pone muy por delante de la mayoría de ingenieros junior que solo han leído tutoriales de 5 minutos.

### ¡Felicidades! Has completado el track de Ingeniería de Datos

Y con esta skill no cierras solo un tema: cierras el track entero. Párate un momento a mirar atrás, porque el camino ha sido largo. Empezaste sin saber qué era una terminal ni una variable. Hoy sabes programar en Python, versionar con Git, levantar entornos con Docker, consultar y modelar datos con SQL y data warehouses, diseñar data lakes con Parquet y entender los table formats modernos como Iceberg, procesar a escala con PySpark, garantizar la calidad de los datos, orquestar pipelines, desplegar en la nube de AWS y diseñar arquitecturas dirigidas por eventos. Eso no es un curso que has terminado: es el arsenal completo de un ingeniero de datos.

Ahora la verdad incómoda: haber completado el track no te convierte en senior de un día para otro. Te convierte en algo más valioso — en alguien peligrosamente capaz de APRENDER cualquier herramienta nueva, porque ya entiendes los fundamentos que hay debajo de todas ellas. Las tecnologías cambiarán (saldrá un motor mejor que Spark, un formato nuevo, otra nube de moda), pero los conceptos que has interiorizado —particionado, idempotencia, modelado dimensional, desacoplamiento, calidad del dato— son para siempre. El siguiente paso ya no es otro tutorial: es construir.