Las entrevistas sobre Kafka evalúan si entiendes cómo se mueven los datos a través de un log: cómo se dividen los temas en particiones, qué orden puedes garantizar, cómo comparten el trabajo los consumidores y qué ocurre cuando algo falla. Las preguntas de escenario sobre lag, duplicados y pérdida de datos son habituales, porque esos son los problemas que aparecen en producción.
A continuación tienes 22 preguntas con respuestas. Detalles como los valores por defecto varían entre versiones de Kafka, así que menciona que comprobarías la versión en uso.
Conceptos básicos
1. ¿Qué es Kafka y para qué se usa?
Kafka es un log de confirmación distribuido y replicado. Los productores añaden registros a los temas y los consumidores los leen a su propio ritmo. Se usa para streaming de eventos, pipelines de logs y métricas, desacoplar servicios, alimentar sistemas de analítica y procesamiento de streams.
2. ¿Qué son los temas, las particiones y los offsets?
Un tema es un flujo de registros con nombre. Cada tema se divide en particiones, y cada partición es un log ordenado y de solo anexado. Cada registro de una partición tiene un offset, un número secuencial que identifica su posición. Los offsets son únicos solo dentro de una partición.
3. ¿Cómo afectan las particiones al orden?
Kafka garantiza el orden solo dentro de una partición. Los registros con la misma clave van a la misma partición por defecto, así que mantienen el orden entre ellos. Entre particiones no hay orden. Si necesitas todos los eventos de un cliente en orden, usa el ID del cliente como clave.
4. ¿Qué es un broker y qué hace el controller?
Un broker es un servidor de Kafka que almacena particiones y atiende a los clientes. Un clúster tiene varios brokers. Uno actúa como controller, que gestiona los metadatos del clúster y el liderazgo de las particiones. Las versiones más recientes de Kafka usan KRaft, un mecanismo de consenso integrado, en lugar de ZooKeeper para estos metadatos.
5. ¿Cómo funciona la replicación?
Cada partición tiene un factor de replicación. Una réplica es el líder, que gestiona las lecturas y escrituras, y las demás son seguidoras que lo copian. Las réplicas sincronizadas (ISR) son las que están al día con el líder. Si el líder falla, se elige un nuevo líder entre las ISR.
Productores
6. ¿Qué significan los ajustes de acks?
| acks | Significado | Compromiso |
|---|---|---|
| 0 | El productor no espera ninguna confirmación | Más rápido, puede perder datos |
| 1 | El líder confirma después de escribir | Puede perder datos si el líder falla antes de replicar |
| all | El líder espera a todas las réplicas sincronizadas | Mayor durabilidad, más latencia |
Para escrituras duraderas, usa acks=all con min.insync.replicas en al menos 2 y un factor de replicación de 3.
7. ¿Cómo evitas mensajes duplicados de un productor?
Activa el productor idempotente (enable.idempotence=true), que permite al broker descartar los duplicados causados por reintentos dentro de una partición. Para escrituras que deben abarcar varias particiones o temas de forma atómica, usa transacciones.
8. ¿Cómo elige un productor la partición?
Si proporcionas una clave, el particionador por defecto la aplica un hash para elegir la partición. Sin clave, el productor reparte los registros entre las particiones (las versiones recientes usan un enfoque sticky para llenar los lotes de forma eficiente). También puedes escribir un particionador personalizado.
9. ¿Qué afecta al rendimiento del productor?
El batching (batch.size, linger.ms), la compresión (como lz4 o zstd), el número de particiones y acks. Los lotes más grandes y la compresión suelen aumentar el rendimiento a costa de un poco de latencia.
Consumidores
10. ¿Qué es un grupo de consumidores?
Un conjunto de consumidores que se reparten el trabajo de leer un topic. Cada partición se asigna a un consumidor del grupo a la vez. Por lo tanto, la cantidad de consumidores útiles en un grupo está limitada por la cantidad de particiones, y los consumidores adicionales quedan inactivos.
11. ¿Qué ocurre durante un rebalanceo?
Cuando un consumidor se une o se va, o cuando cambian las particiones, el grupo reasigna las particiones. Durante un rebalanceo clásico, el consumo se pausa mientras esto sucede. El rebalanceo cooperativo y la membresía estática reducen la interrupción. Los rebalanceos frecuentes suelen deberse a consumidores que tardan demasiado en procesar (max.poll.interval.ms) o que no envían heartbeats.
12. ¿Cómo se confirman los offsets?
Los consumidores confirman el offset del siguiente registro a leer, que se almacena en un topic interno. La confirmación automática es simple, pero puede confirmar antes de que termine el procesamiento. Las confirmaciones manuales después del procesamiento te dan control sobre qué significa "terminado".
13. ¿Qué significan at-most-once, at-least-once y exactly-once?
- At-most-once: confirmar el offset antes de procesar. Una caída puede perder registros.
- At-least-once: procesar y luego confirmar. Una caída puede provocar reprocesamiento, así que los duplicados son posibles.
- Exactly-once: el efecto ocurre una sola vez. En Kafka esto es posible dentro de Kafka usando productores idempotentes, transacciones y consumidores read_committed. Cuando se escribe en un sistema externo, normalmente necesitas escrituras idempotentes o deduplicación por una clave.
Una buena respuesta dice que "exactly once" depende de dónde estén los efectos secundarios.
14. ¿Cómo manejarías un mensaje venenoso que siempre falla?
Captura el error, reintenta una cantidad limitada de veces, luego envía el registro a un topic de mensajes muertos con los detalles, confirma el offset y continúa. Genera alertas sobre el topic de mensajes muertos para que alguien lo investigue.
Operaciones y escenarios
15. El lag del consumidor está creciendo. ¿Cómo lo diagnosticas?
- Revisa qué particiones tienen lag. Una sola partición caliente apunta a una clave sesgada. Lag en todas partes apunta a un procesamiento lento o a muy pocos consumidores.
- Revisa el tiempo de procesamiento por registro y las llamadas posteriores, como a una base de datos.
- Revisa si hay rebalanceos frecuentes.
- Revisa si aumentó la tasa del productor.
- Soluciona con más consumidores (hasta la cantidad de particiones), procesamiento más rápido, manejo por lotes o más particiones.
16. ¿Cuándo deberías aumentar la cantidad de particiones?
Cuando necesitas más paralelismo del que los consumidores actuales pueden ofrecer, o cuando el throughput por partición es el límite. Ten cuidado: agregar particiones cambia el mapeo de clave a partición para los registros nuevos, así que el orden por clave puede romperse con el cambio. Planifica la cantidad de particiones desde el principio cuando el orden importa.
17. ¿Cómo se retienen los datos y qué es la compactación de log?
Por defecto, Kafka elimina los segmentos antiguos por tiempo o tamaño (retention.ms, retention.bytes). Con la compactación de log, Kafka conserva al menos el último valor de cada clave, lo que encaja bien con un changelog o un topic tipo tabla. Un valor nulo (un tombstone) marca una clave para su eliminación.
18. ¿Qué pasa si falla un broker?
Las particiones lideradas por ese broker eligen nuevos líderes del ISR. Los clientes actualizan los metadatos y continúan. Si no hay una réplica sincronizada disponible, la partición queda no disponible a menos que permitas la elección de líder no limpia, lo que arriesga pérdida de datos.
19. ¿Cómo aseguras un clúster de Kafka?
TLS para el cifrado en tránsito, SASL (como SCRAM u OAuth) o TLS mutuo para la autenticación, ACLs para la autorización sobre topics y grupos, y controles de red. Cifra los campos sensibles a nivel de aplicación si es necesario.
20. ¿Cómo monitoreas Kafka?
Las señales clave son el lag del consumidor, las particiones subreplicadas, las particiones fuera de línea, la latencia de solicitudes, el uso de disco y las tasas de reducción y expansión del ISR, recolectadas mediante métricas JMX y herramientas como Prometheus y Grafana.
Preguntas de diseño
21. ¿Cuándo elegirías Kafka en lugar de una cola de mensajes como RabbitMQ o SQS?
Elige Kafka cuando necesitas alto throughput, reproducir eventos pasados, varios consumidores independientes del mismo stream o procesamiento de streams. Elige una cola tradicional para enrutamiento por mensaje, colas de tareas simples o cuando no quieres gestionar particiones.
22. Diseña un pipeline de eventos de pedidos.
"Los pedidos van a un topic orders con clave por ID de pedido, para que los eventos de un pedido mantengan el orden. Usaría tres o más brokers, un factor de replicación de 3, acks=all y productores idempotentes. Los consumidores de facturación, inventario y analítica usan cada uno su propio grupo. Las escrituras de facturación son idempotentes por ID de pedido, los registros fallidos van a un topic de mensajes muertos y monitorearía el lag por grupo. Elegiría la cantidad de particiones según el throughput máximo y la cantidad esperada de consumidores, con margen para crecer."
Cómo prepararte
Si puedes, levanta un Kafka local, escribe un productor y un grupo de consumidores, detén un consumidor y observa el rebalanceo. Rompe algo a propósito, como un consumidor lento, y mira el lag. Prepara una historia real sobre un problema de pipeline de datos que hayas resuelto. Para temas relacionados, consulta nuestras guías sobre Databricks y entrevistas de diseño de sistemas.
Practica explicar en voz alta las garantías de entrega, porque ahí es donde las respuestas se vuelven vagas. Una entrevista simulada y una transcripción te mostrarán dónde. Sigue las reglas del empleador sobre el uso de herramientas de IA en cualquier entrevista en vivo.
Practica respuestas de entrevista sobre Kafka con YesToTheOffer
Realiza una entrevista técnica simulada, explica las garantías de entrega en voz alta y revisa tu transcripción después. 30 minutos gratis, sin suscripción.
