Apache Kafka para la empresa mediana española: implementación práctica

Kafka no es solo para gigantes

Hay una percepción extendida de que Apache Kafka es una herramienta para empresas que procesan millones de eventos por segundo. LinkedIn, Netflix, Uber. Y es cierto que ahí nació y ahí brilla. Pero la realidad es que Kafka resuelve problemas que tienen empresas de todos los tamaños: desacoplar productores y consumidores de datos, garantizar el orden de los eventos, y permitir que múltiples sistemas lean los mismos datos sin interferir entre sí.

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 española que procesa entre 10.000 y 1.000.000 de eventos diarios — pedidos de un e-commerce, movimientos de almacén, transacciones financieras, logs de aplicaciones — Kafka es una opción viable y, en muchos casos, la mejor.

Cuándo Kafka tiene sentido (y cuándo no)

Kafka tiene sentido cuando:

• Múltiples sistemas necesitan reaccionar al mismo evento. Un pedido nuevo debe actualizar el stock, notificar al almacén, enviar confirmación al cliente, y alimentar el dashboard de operaciones. Sin Kafka, esto se convierte en una maraña de llamadas HTTP punto a punto que se rompe cada vez que un sistema está caído.
• Necesitas garantía de orden. Los eventos deben procesarse en secuencia: el pago antes del envío, la reserva antes de la confirmación. Las colas tradicionales no garantizan orden entre consumidores distintos.
• Necesitas replayability. Quieres poder reprocesar eventos pasados cuando corriges un bug o añades un 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 fracción de la complejidad operativa.
• Necesitas RPC o request-reply. Kafka es un sistema de mensajería asíncrono. Si necesitas enviar una petición y esperar la respuesta, no es la herramienta adecuada.
• No tienes capacidad operativa para mantenerlo. Un cluster de Kafka requiere atención: monitorización, rebalanceo de particiones, gestión 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 más simple.

Sizing para la empresa mediana

El sobredimensionamiento es el error más común. Un equipo lee que LinkedIn tiene cientos de brokers y asume que necesita algo similar. Para una empresa mediana, los números son mucho más modestos.

Estimación 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 tráfico ocurre en 4 horas, el pico sube a 250 eventos por minuto. Añade un factor 3x para absorber picos imprevistos. Para 100.000 eventos diarios, dimensiona para 750 eventos por minuto.

Tamaño de mensaje: El tamaño medio importa para calcular almacenamiento y throughput de red. Un evento de pedido típico 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 más. Para la empresa mediana típica, asume 2KB de media.

Infraestructura mínima viable:

Para 10K-100K eventos/día:

• 3 brokers (el mínimo para tolerancia a fallos) con 2 vCPUs y 4GB RAM cada uno.
• Disco SSD: 50GB por broker (con retención de 7 días 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/día:

• 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 está entre 200 y 500 euros mensuales, y te ahorras la operativa.

Coste real: Un cluster mínimo 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 básico y escala con throughput. La decisión entre self-managed y gestionado depende del coste del tiempo de tu equipo, no solo del coste de infraestructura.

Diseño de topics

El diseño de topics es donde la mayoría de los errores ocurren y donde más impacto tiene hacerlo bien.

Una entidad, un topic. El patrón más robusto: un topic por tipo de entidad de negocio. orders, payments, shipments, inventory-updates. Cada topic contiene todos los eventos relacionados con esa entidad: creación, actualización, cancelación. El tipo de evento va en un campo del mensaje, no en el nombre del topic.

No caigas en la tentación de crear topics por tipo de evento (order-created, order-updated, order-cancelled). Esto multiplica el número 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 número de particiones determina el paralelismo máximo de consumo. Cada partición puede tener un único consumidor activo dentro de un consumer group. Regla práctica: empieza con el número 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.

Atención: una vez creado un topic con N particiones, puedes añadir pero no reducir. Empieza conservador.

Clave de particionamiento: La clave determina a qué partición va cada mensaje. Mensajes con la misma clave siempre van a la misma partición, 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 estén en orden. Si no defines clave, Kafka distribuye round-robin y pierdes la garantía de orden.

Retención: Por defecto Kafka retiene mensajes 7 días. Para la empresa mediana, recomendamos 14 días como mínimo (cubre dos fines de semana, vacaciones cortas, y la mayoría de los escenarios de reprocesamiento). Para topics críticos como pagos y pedidos, 30 días o ilimitado con compaction (Kafka guarda solo el último 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 envíe 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 patrón 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 único consumidor.

Ejemplo práctico: 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: envía email y SMS de confirmación. 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 métrica crítica. Mide cuántos 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 lógica o añade más 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 métrica más importante de tu cluster después del espacio en disco.

Operativa: el runbook que necesitas

Kafka en producción requiere atención regular. Estos son los procedimientos que documentamos para cada implementación.

Monitorización continua:

• Espacio en disco por broker (alerta al 70%, crítico 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 periódico:

• Revisar y ajustar retención 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 caída de un broker y verificar que el cluster se recupera sin pérdida de datos.

Escenarios de fallo y respuesta:

Broker caído: Si hay 3 brokers y cae uno, el cluster sigue operando con las réplicas. Verificar que las particiones se han reasignado. Reiniciar el broker o reemplazarlo. Si no se recupera en 30 minutos, forzar reasignación de particiones.

Consumer bloqueado: Identificar qué consumer group tiene lag creciente. Verificar logs del consumidor. Causas comunes: excepción 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 retención temporalmente (retention.ms), eliminar topics no críticos, o añadir disco. Nunca debería llegar aquí si la alerta al 70% funciona.

Alternativas que deberías considerar primero

Antes de instalar Kafka, evalúa si una solución más simple resuelve tu problema.

Redis Streams: Si tu volumen es bajo (<10K eventos/día), Redis Streams ofrece semántica similar a Kafka (consumer groups, persistence) con una operativa mucho más simple. Muchas empresas ya tienen Redis para cache, así que no es una dependencia nueva.

Amazon SQS/SNS: Si estás en AWS y necesitas colas y pub-sub básico sin garantía de orden global, SQS+SNS es serverless, no requiere operativa, y cuesta céntimos hasta volúmenes considerables.

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

La decisión siempre es la misma: usa la herramienta más 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 sobreingeniería

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

1. Semana 1-2: Montar el cluster (3 brokers, preferiblemente con KRaft). Configurar monitorización básica. Crear los 3-5 topics iniciales con schema registrado.
2. Semana 3-4: Migrar el primer caso de uso. Elegir el más simple (normalmente logs o eventos de auditoría). Verificar que produce, consume y la monitorización funciona.
3. Semana 5-8: Migrar los casos de uso de negocio. Uno a la vez. Pedidos, pagos, inventario. Cada migración incluye: producer, consumer(s), monitorización de lag, y un playbook de rollback.
4. Mes 3+: Estabilizar. Ajustar particiones y retención basándose en datos reales. Documentar runbooks. Formar al equipo en operativa.

Si necesitas ayuda con el diseño e implementación de tu cluster Kafka, nuestro equipo de ingeniería de datos ha desplegado esta arquitectura para empresas medianas en sectores como logística y retail. El error más común no es elegir mal la herramienta. Es implementarla toda de golpe en lugar de incrementalmente. Empieza con un topic. Aprende. Añade el siguiente.