Apache Kafka para la empresa mediana espanola: implementacion practica

Kafka no es solo para gigantes

Hay una percepcion extendida de que Apache Kafka es una herramienta para empresas que procesan millones de eventos por segundo. LinkedIn, Netflix, Uber. Y es cierto que ahi nacio y ahi brilla. Pero la realidad es que Kafka resuelve problemas que tienen empresas de todos los tamanos: desacoplar productores y consumidores de datos, garantizar el orden de los eventos, y permitir que multiples sistemas lean los mismos datos sin interferir entre si.

La pregunta no es si tu empresa es lo suficientemente grande para Kafka. La pregunta es si tienes un problema que Kafka resuelve y si la complejidad operativa se justifica. Para una empresa mediana espanola que procesa entre 10.000 y 1.000.000 de eventos diarios — pedidos de un e-commerce, movimientos de almacen, transacciones financieras, logs de aplicaciones — Kafka es una opcion viable y, en muchos casos, la mejor.

Cuando Kafka tiene sentido (y cuando no)

Kafka tiene sentido cuando:

• Multiples sistemas necesitan reaccionar al mismo evento. Un pedido nuevo debe actualizar el stock, notificar al almacen, enviar confirmacion al cliente, y alimentar el dashboard de operaciones. Sin Kafka, esto se convierte en una marana de llamadas HTTP punto a punto que se rompe cada vez que un sistema esta caido.
• Necesitas garantia de orden. Los eventos deben procesarse en secuencia: el pago antes del envio, la reserva antes de la confirmacion. Las colas tradicionales no garantizan orden entre consumidores distintos.
• Necesitas replayability. Quieres poder reprocesar eventos pasados cuando corriges un bug o anadesun nuevo consumidor. Kafka retiene mensajes (configurable, desde horas hasta indefinidamente), lo que permite “rebobinar” y reprocesar.

Kafka no tiene sentido cuando:

• Tienes un volumen bajo de eventos y pocos consumidores. Si son menos de 1.000 eventos diarios con 2-3 consumidores, una cola simple (Redis Streams, SQS, RabbitMQ) resuelve el problema con una fraccion de la complejidad operativa.
• Necesitas RPC o request-reply. Kafka es un sistema de mensajeria asincrono. Si necesitas enviar una peticion y esperar la respuesta, no es la herramienta adecuada.
• No tienes capacidad operativa para mantenerlo. Un cluster de Kafka requiere atencion: monitorizacion, rebalanceo de particiones, gestion de disco. Si no tienes un equipo que pueda dedicar tiempo a esto, considera servicios gestionados (Confluent Cloud, Amazon MSK, Upstash Kafka) o una alternativa mas simple.

Sizing para la empresa mediana

El sobredimensionamiento es el error mas comun. Un equipo lee que LinkedIn tiene cientos de brokers y asume que necesita algo similar. Para una empresa mediana, los numeros son mucho mas modestos.

Estimacion de volumen: Calcula tu throughput pico, no medio. Si procesas 100.000 eventos diarios distribuidos uniformemente, son unos 70 eventos por minuto. Pero si el 60% del trafico ocurre en 4 horas, el pico sube a 250 eventos por minuto. Anade un factor 3x para absorber picos imprevistos. Para 100.000 eventos diarios, dimensiona para 750 eventos por minuto.

Tamano de mensaje: El tamano medio importa para calcular almacenamiento y throughput de red. Un evento de pedido tipico en JSON con todos los campos de negocio ocupa entre 1KB y 5KB. Un evento de log puede ocupar 500 bytes. Un evento con documentos adjuntos (no recomendado, pero ocurre) puede ocupar 50KB o mas. Para la empresa mediana tipica, asume 2KB de media.

Infraestructura minima viable:

Para 10K-100K eventos/dia:

• 3 brokers (el minimo para tolerancia a fallos) con 2 vCPUs y 4GB RAM cada uno.
• Disco SSD: 50GB por broker (con retencion de 7 dias y 2KB de media por mensaje).
• ZooKeeper: 3 nodos con 1 vCPU y 2GB RAM (o usar KRaft, el modo sin ZooKeeper disponible desde Kafka 3.3, que elimina esta dependencia).

Para 100K-1M eventos/dia:

• 3-5 brokers con 4 vCPUs y 8GB RAM.
• Disco SSD: 100-200GB por broker.
• Considerar seriamente un servicio gestionado a este volumen. El coste de Confluent Cloud o Amazon MSK para este throughput esta entre 200 y 500 euros mensuales, y te ahorras la operativa.

Coste real: Un cluster minimo en AWS (3 instancias t3.medium para brokers, 3 t3.small para ZooKeeper) cuesta aproximadamente 250 euros al mes. Con un servicio gestionado, el coste parte de 150 euros mensuales para el tier basico y escala con throughput. La decision entre self-managed y gestionado depende del coste del tiempo de tu equipo, no solo del coste de infraestructura.

Diseno de topics

El diseno de topics es donde la mayoria de los errores ocurren y donde mas impacto tiene hacerlo bien.

Una entidad, un topic. El patron mas robusto: un topic por tipo de entidad de negocio. orders, payments, shipments, inventory-updates. Cada topic contiene todos los eventos relacionados con esa entidad: creacion, actualizacion, cancelacion. El tipo de evento va en un campo del mensaje, no en el nombre del topic.

No caigas en la tentacion de crear topics por tipo de evento (order-created, order-updated, order-cancelled). Esto multiplica el numero de topics, complica el consumo (un consumidor que necesita el estado completo de un pedido debe leer tres topics), y hace imposible garantizar el orden entre eventos del mismo pedido.

Particiones: El numero de particiones determina el paralelismo maximo de consumo. Cada particion puede tener un unico consumidor activo dentro de un consumer group. Regla practica: empieza con el numero de consumidores que necesitas en paralelo, multiplicado por 2 (para crecimiento). Para la empresa mediana, 6-12 particiones por topic es un punto de partida razonable.

Atencion: una vez creado un topic con N particiones, puedes anadir pero no reducir. Empieza conservador.

Clave de particionamiento: La clave determina a que particion va cada mensaje. Mensajes con la misma clave siempre van a la misma particion, lo que garantiza orden. Usa el ID de la entidad: order_id para el topic de pedidos, customer_id si necesitas que todos los eventos de un cliente esten en orden. Si no defines clave, Kafka distribuye round-robin y pierdes la garantia de orden.

Retencion: Por defecto Kafka retiene mensajes 7 dias. Para la empresa mediana, recomendamos 14 dias como minimo (cubre dos fines de semana, vacaciones cortas, y la mayoria de los escenarios de reprocesamiento). Para topics criticos como pagos y pedidos, 30 dias o ilimitado con compaction (Kafka guarda solo el ultimo mensaje por clave, ideal para estado).

Schema: Registra el schema de cada topic en un Schema Registry (Confluent Schema Registry o Apicurio). Usa Avro o Protobuf, no JSON puro. JSON es tentador por su simplicidad, pero sin schema enforcement nada impide que un productor envie un mensaje con un campo renombrado o un tipo cambiado, rompiendo consumidores downstream. Con Avro y Schema Registry, los cambios incompatibles se rechazan antes de publicar.

Consumer groups: el patron que tienes que dominar

Los consumer groups son el mecanismo de Kafka para distribuir trabajo entre consumidores. Cada grupo recibe una copia de cada mensaje. Dentro de un grupo, cada mensaje va a un unico consumidor.

Ejemplo practico: el topic orders tiene 3 consumidores.

• Consumer group order-processing: procesa el pedido, actualiza stock, genera albarán. 3 instancias para paralelismo.
• Consumer group analytics: alimenta el dashboard de operaciones en tiempo real. 1 instancia suficiente.
• Consumer group notification-service: envia email y SMS de confirmacion. 2 instancias.

Cada grupo lee todos los mensajes independientemente. Dentro del grupo order-processing, los 3 consumidores se reparten las particiones. Si el topic tiene 12 particiones, cada consumidor procesa 4.

Consumer lag es la metrica critica. Mide cuantos mensajes hay pendientes de procesar en un consumer group. Un lag que crece significa que los consumidores no mantienen el ritmo del productor. Las causas habituales: procesamiento lento por consumidor (optimiza la logica o anade mas instancias), rebalanceo frecuente (ajusta session.timeout.ms y heartbeat.interval.ms), o un consumidor bloqueado (timeout en una llamada HTTP downstream).

Monitoriza el consumer lag con Kafka Exporter + Prometheus + Grafana. Es la metrica mas importante de tu cluster despues del espacio en disco.

Operativa: el runbook que necesitas

Kafka en produccion requiere atencion regular. Estos son los procedimientos que documentamos para cada implementacion.

Monitorizacion continua:

• Espacio en disco por broker (alerta al 70%, critico al 85%).
• Consumer lag por grupo (alerta si crece durante 5 minutos consecutivos).
• Under-replicated partitions (debe ser 0; cualquier valor indica un broker con problemas).
• Request latency de produce y fetch (p99 por debajo de 100ms para la empresa mediana).

Mantenimiento periodico:

• Revisar y ajustar retencion mensualmente (el dato crece y el disco no).
• Verificar que los pipelines de datos downstream procesan al ritmo esperado.
• Actualizar brokers trimestralmente (Kafka tiene releases frecuentes con fixes de seguridad).
• Testear recovery: simular la caida de un broker y verificar que el cluster se recupera sin perdida de datos.

Escenarios de fallo y respuesta:

Broker caido: Si hay 3 brokers y cae uno, el cluster sigue operando con las replicas. Verificar que las particiones se han reasignado. Reiniciar el broker o reemplazarlo. Si no se recupera en 30 minutos, forzar reasignacion de particiones.

Consumer bloqueado: Identificar que consumer group tiene lag creciente. Verificar logs del consumidor. Causas comunes: excepcion no capturada, timeout en dependencia externa, thread deadlock. Reiniciar el consumidor. Si el problema persiste, pausar el consumer group y investigar.

Disco lleno: Emergencia. Reducir retencion temporalmente (retention.ms), eliminar topics no criticos, o anadir disco. Nunca deberia llegar aqui si la alerta al 70% funciona.

Alternativas que deberias considerar primero

Antes de instalar Kafka, evalua si una solucion mas simple resuelve tu problema.

Redis Streams: Si tu volumen es bajo (<10K eventos/dia), Redis Streams ofrece semantica similar a Kafka (consumer groups, persistence) con una operativa mucho mas simple. Muchas empresas ya tienen Redis para cache, asi que no es una dependencia nueva.

Amazon SQS/SNS: Si estas en AWS y necesitas colas y pub-sub basico sin garantia de orden global, SQS+SNS es serverless, no requiere operativa, y cuesta centimos hasta volumenes considerables.

RabbitMQ: Si necesitas routing complejo (exchanges, bindings, dead letter queues) y tu volumen es moderado, RabbitMQ es mas maduro en ese espacio y mas simple de operar que Kafka.

La decision siempre es la misma: usa la herramienta mas simple que resuelve tu problema actual con margen para crecer. Si esa herramienta es Kafka, implementala bien. Si no lo es, no la fuerces.

Empezar sin sobreingenieria

Si decides que Kafka es la herramienta correcta, el plan de implementacion para una empresa mediana es:

1. Semana 1-2: Montar el cluster (3 brokers, preferiblemente con KRaft). Configurar monitorizacion basica. Crear los 3-5 topics iniciales con schema registrado.
2. Semana 3-4: Migrar el primer caso de uso. Elegir el mas simple (normalmente logs o eventos de auditoria). Verificar que produce, consume y la monitorizacion funciona.
3. Semana 5-8: Migrar los casos de uso de negocio. Uno a la vez. Pedidos, pagos, inventario. Cada migracion incluye: producer, consumer(s), monitorizacion de lag, y un playbook de rollback.
4. Mes 3+: Estabilizar. Ajustar particiones y retencion basandose en datos reales. Documentar runbooks. Formar al equipo en operativa.

Si necesitas ayuda con el diseno e implementacion de tu cluster Kafka, nuestro equipo de ingenieria de datos ha desplegado esta arquitectura para empresas medianas en sectores como logistica y retail. El error mas comun no es elegir mal la herramienta. Es implementarla toda de golpe en lugar de incrementalmente. Empieza con un topic. Aprende. Anade el siguiente.