Apache Kafka 4.0, lanzado en marzo de 2025, elimina ZooKeeper por completo. KRaft es ahora la única forma de ejecutar un clúster, y los equipos que siguen en modo ZooKeeper deben migrar a través de Kafka 3.9 antes de poder actualizar. Es un cambio operativo significativo, y llega justo cuando muchos equipos de plataforma se hacen una pregunta más difícil: si ejecutar Kafka en capas cloud compartidas sigue teniendo sentido dado el rendimiento y los requisitos de latencia que realmente tienen.

La respuesta honesta es: depende de tus requisitos de P99, tu volumen de datos y cuánto de tu factura quieres ceder a un servicio gestionado. Este artículo analiza las decisiones de arquitectura más importantes al migrar cargas de trabajo compatibles con Kafka a hardware dedicado, donde la física del problema se convierte en tu ventaja y no en el margen de otro.

Nosotros ejecutamos NATS JetStream como backbone de streaming de eventos en producción en cuatro centros de datos europeos. Eso significa que tenemos experiencia operativa directa con las decisiones de ajuste que se describen a continuación, no solo la teoría.

La latencia de red sigue la velocidad de la luz en fibra, aproximadamente 5 microsegundos por kilómetro, más la sobrecarga de enrutamiento. La latencia dentro del mismo rack se sitúa entre 0,1 y 0,5 ms en un sentido; cruzar zonas de disponibilidad dentro de una región añade entre 0,5 y 2 ms adicionales. Los saltos entre regiones a lo largo de un continente oscilan entre 15 y 40 ms. Estos son límites físicos, no problemas de configuración. Cuando un servicio de Kafka gestionado enruta tu tráfico de replicación entre zonas de disponibilidad, pagas ese coste adicional en cada escritura con acks=all. En bare metal, tú eliges la topología: brokers en el mismo rack, en el mismo switch, con tráfico de replicación que nunca sale de tu jaula.

Qué limita realmente el rendimiento de tus particiones

Una partición de un topic de Kafka es un archivo de log escrito secuencialmente en disco en un broker. Su techo de rendimiento lo determinan tres factores: la NIC del broker, las IOPS de escritura del disco y el tráfico de replicación de red hacia las réplicas seguidoras. En una instancia cloud compartida, compites por los tres con otros inquilinos. En hardware dedicado con almacenamiento NVMe, esos recursos son exclusivamente tuyos.

Los clústeres de Kafka con configuraciones de tres a cinco brokers y almacenamiento NVMe mantienen de forma rutinaria tasas de GB/s de un solo dígito. El propio conjunto de benchmarks del proyecto Apache Kafka muestra que Kafka 4.x supera los 100 MB/s por broker en hardware de gama media. Redpanda Labs publicó en 2024 cifras de 1,4 millones de mensajes por segundo en un clúster de cinco nodos sobre hardware de gama media. Estas cifras son alcanzables en bare metal; reproducirlas de forma consistente en instancias cloud con rendimiento variable de disco y red es mucho más difícil.

La distinción entre “normalmente rápido” y “siempre rápido” importa sobre todo en la cola. Kafka mantiene latencias ajustadas hasta aproximadamente el percentil 94 antes de que los costes de persistencia en disco se hagan notar. Las unidades NVMe eliminan la penalización de búsqueda mecánica y ofrecen IOPS predecibles bajo carga de escritura sostenida, que es lo que evita que el P99 se desvíe de la mediana en producción.

Replicación, durabilidad y el equilibrio con la latencia

El factor de replicación y el modo de confirmación definen juntos tu contrato de durabilidad-latencia. Con acks=all, la latencia equivale al tiempo base de escritura más el viaje de ida y vuelta a la réplica sincronizada más lenta. Con acks=1, la latencia equivale al tiempo base de escritura más el vaciado local a disco únicamente. Ninguna opción es universalmente correcta; la respuesta adecuada depende de qué estás transmitiendo y qué coste tiene perder un mensaje.

La durabilidad no es gratuita, y la latencia no es negociable. La pregunta arquitectónica es cuál de las dos estás pagando y si controlas el tipo de cambio.

En bare metal, tú controlas dónde se ubican tus réplicas. Colocar las tres réplicas de un topic crítico en brokers del mismo rack, conectados por una VLAN de replicación dedicada, mantiene el tiempo de ida y vuelta del ISR por debajo de 0,5 ms. Distribuirlas entre zonas de disponibilidad cloud por “resiliencia” añade entre 1 y 2 ms a cada escritura confirmada, y pagas ese tráfico de red por GB.

Número de particiones, particiones calientes y límites de paralelismo

Un mayor número de particiones incrementa el paralelismo y el rendimiento, pero también aumenta la carga del broker: más descriptores de archivo abiertos, más conexiones de replicación y más metadatos que el controlador KRaft debe gestionar. La regla práctica es dimensionar las particiones según el paralelismo objetivo de los consumidores, no según un máximo teórico. La restricción que impone Kafka es que una partición solo puede ser consumida por un consumidor dentro de un grupo, por lo que el número de particiones establece el techo de consumidores que pueden trabajar en paralelo.

Las particiones calientes son un problema de claves, no de hardware, pero el bare metal hace que sean más baratas de diagnosticar. Cuando ciertas particiones reciben mucho más tráfico que otras, los brokers que las alojan se convierten en cuellos de botella mientras otros permanecen ociosos. La causa habitual es una estrategia de claves deficiente: usar un campo de baja cardinalidad como clave de mensaje, o enrutar todos los mensajes sin clave a una única partición. En un clúster dedicado, la utilización de CPU y disco por broker es visible sin las abstracciones del proveedor cloud de por medio, por lo que los desequilibrios afloran más rápido.

Almacenamiento por niveles: separar el coste de retención del coste de rendimiento

El almacenamiento por niveles de Kafka, introducido mediante KIP-405, permite descargar segmentos de log más antiguos a almacenamiento de objetos mientras se mantienen los datos recientes en NVMe local para lecturas de cola con baja latencia. Esto tiene un impacto económico importante a escala: retener 30 días de datos de un topic de alto volumen en NVMe es caro; hacerlo en almacenamiento de objetos no lo es. La arquitectura mantiene tu ruta caliente rápida y tu coste de retención manejable.

En un despliegue bare metal autogestionado, tú eliges el almacén de objetos. Eso significa que tu destino de almacenamiento por niveles puede ser un almacén de objetos europeo soberano bajo tu propio control contractual, no el bucket de un proveedor cloud con sede en Estados Unidos. Para cargas de trabajo de servicios financieros, sanidad y defensa, esa distinción no es académica.

Implicaciones operativas de Kafka 4.0 para equipos en bare metal

La arquitectura exclusiva de KRaft en Kafka 4.0 elimina por completo el ensemble de ZooKeeper de tu superficie operativa. Es una simplificación real: menos procesos que monitorizar, menos modos de fallo que gestionar y un único sistema de metadatos sobre el que razonar. El controlador KRaft gestiona los metadatos del clúster a través de un log de consenso Raft, y la ruta de migración desde el modo ZooKeeper pasa por Kafka 3.9 como versión puente recomendada.

Java 17 es ahora obligatorio para brokers, Connect y herramientas en Kafka 4.0, con Java 11 requerido para clientes y Streams. Es un cambio que rompe la compatibilidad para los equipos que ejecutan versiones antiguas de JVM en bare metal, y debe formar parte de tu planificación de actualización antes de tocar los binarios de Kafka.

KIP-848, el nuevo protocolo de grupos de consumidores disponible de forma general en 4.0, mejora significativamente el rendimiento de los rebalanceos. Los rebalanceos en grupos de consumidores grandes han sido históricamente una fuente de picos de latencia y pérdidas de disponibilidad; el nuevo protocolo reduce el radio de explosión cuando un único consumidor se une al grupo o lo abandona. En bare metal, donde controlas la topología de red y puedes colocar consumidores junto a los brokers, la combinación de KIP-848 y replicación de baja latencia reduce sustancialmente el impacto en la cola de los rebalanceos.

La estructura de costes del modelo autogestionado

El precio de Kafka gestionado suele estructurarse en torno a horas de partición, transferencia de datos y almacenamiento, con el margen del proveedor integrado en cada concepto. A volúmenes bajos, ese modelo es razonable. A volúmenes altos, la aritmética se invierte: pagas un coste por mensaje sobre tráfico que el hardware dedicado podría gestionar por el coste del propio hardware y el tiempo de ingeniería necesario para operarlo.

El punto de cruce varía según la carga de trabajo, pero los equipos con un rendimiento sostenido superior a unos pocos cientos de MB/s comprueban de forma consistente que Kafka autogestionado en bare metal es más económico en un horizonte de tres años, incluso teniendo en cuenta la sobrecarga operativa. El coste de infraestructura es fijo; el coste del servicio gestionado escala con tu volumen de datos. En DIVERSITY, nuestra flota de bare metal opera bajo garantías de disponibilidad Tier III, interconexiones carrier-neutral, certificación ISO 27001 y un SLA contractual del 99,9% de tiempo de actividad. No son frases de marketing; son los términos que tus equipos de compras y legal pueden revisar y exigirnos.

Los patrones de arquitectura anteriores no son hipotéticos. Son las decisiones que tomas cuando eres dueño del hardware, la red y la responsabilidad operativa. La capa cloud gestionada te abstrae de esas decisiones y te cobra por ello. Si ese intercambio merece la pena depende de tu escala, tus requisitos de latencia y el grado de control operativo que necesitas sobre tu infraestructura de streaming de eventos.