Pregunta y cuándo aplica
Una plataforma utiliza Kafka para flujos de eventos y colas de tareas. Un Consumer Group tradicional asigna cada partición a un único miembro, mientras que el equipo desea usar los Share Groups de Kafka 4.1 para obtener una concurrencia más similar a la de una cola. Decide qué cargas de trabajo son adecuadas y cómo controlar el riesgo de una funcionalidad en preview.
Qué evalúa el entrevistador
- Distinguir el procesamiento de flujos particionados de la semántica de entrega de colas compartidas.
- Explicar los límites de adquisición, el reconocimiento (acknowledgment), la reentrega por fallos y el ordenamiento.
- Combinar en un solo diseño la equidad multi-tenant, el lag, la idempotencia y la observabilidad.
- Establecer criterios de compatibilidad, despliegue canario (canary), reproducción (replay) y rollback para una función en preview.
Preguntas de clarificación antes de responder
- ¿El trabajo requiere ordenamiento por clave y estado local de partición, o solo el procesamiento eventual de cada registro?
- ¿Un registro fallido debe reintentarse inmediatamente, más tarde o a través de una cola de mensajes no procesables (dead-letter queue)?
- ¿Los tenants comparten topics y capacidad de consumidores, y existe una identidad de tenant estable?
- ¿Los efectos secundarios posteriores (downstream) son idempotentes y el procesamiento puede ser concurrente o duplicado?
- ¿La versión de Kafka, el cliente, las herramientas de administración y la plataforma gestionada admiten Share Groups?
Estructura de respuesta en 30 segundos
Los Consumer Groups utilizan las particiones como límites de paralelismo y ordenamiento, adaptándose a agregaciones en streaming y estado basado en claves. Los Share Groups se asemejan más a una cola compartida: múltiples consumidores pueden adquirir diferentes registros de una misma topic-partition, mientras que el clúster limita cuántos registros se pueden adquirir por partición. Clasificaría según la semántica de negocio, validaría el reconocimiento, la reentrega, la idempotencia y la equidad, y luego implementaría un despliegue canario para la función en preview manteniendo una ruta de rollback hacia Consumer Groups.
Análisis detallado paso a paso
Paso 1: Comenzar con la semántica de procesamiento, no con el nombre de la API
Si el procesamiento depende del orden de las particiones, el estado de ventanas o la agregación por claves, la asignación de Consumer Groups es más fácil de razonar. Si las tareas son independientes, necesitan mayor concurrencia y aceptan el reconocimiento de estilo cola, los Share Groups son candidatos. No migres simplemente porque un benchmark prometa un mayor rendimiento (throughput).
Paso 2: Comparar límites de concurrencia y adquisición
El paralelismo de los grupos tradicionales está delimitado principalmente por el número de particiones; un miembro gestiona una partición a la vez. Los Share Groups permiten que múltiples consumidores adquieran registros de una misma topic-partition, pero el clúster aún limita el número adquirido por partición. Mide el producto del tamaño del lote (batch size), el tiempo de procesamiento y la capacidad posterior (downstream).
Paso 3: Definir reconocimiento, fallos y reentrega
Antes de la migración, define cuándo un registro es exitoso, si un fallo lo pone a disposición de otro consumidor y si la reentrega puede solaparse con el trabajo anterior. Utiliza claves de idempotencia, una tabla de desduplicación o transacciones repetibles para escrituras externas. Envía los fallos irrecuperables a una dead-letter queue con el motivo, el tenant y el recuento de intentos.
Paso 4: Gestionar el ordenamiento y el estado
La semántica de colas compartidas puede invalidar los supuestos sobre el orden de las particiones. Mantén el trabajo serial por clave en Consumer Groups, o implementa serialización a nivel de clave y comprobaciones de versión en la aplicación. El almacenamiento de estado debe registrar la versión del evento, el procesador y el estado de reintento para que las actualizaciones concurrentes no se sobrescriban silenciosamente.
Paso 5: Desarrollar equidad multi-tenant y contrapresión (backpressure)
Una ráfaga de un tenant en un topic compartido puede crear un problema de vecino ruidoso (noisy neighbor). Incluye una identidad de tenant estable y observa el tiempo de espera, el rendimiento y la tasa de fallos por tenant. Añade cuotas en la aplicación, límites de adquisición por lote, separación de topics o bulkheads posteriores cuando sea necesario. Las bases de datos y las API externas necesitan sus propios límites de concurrencia.
Paso 6: Validar las rutas de preview y de operaciones
La documentación de Kafka etiqueta los Share Groups como preview y no habilitados por defecto. Verifica primero la compatibilidad de brokers, clientes, herramientas de administración, métricas, recuperación ante fallos y actualizaciones. Utiliza eventos sintéticos para probar reinicios, reducción de consumidores, reconocimientos duplicados, cambios de brokers, lag y dead letters.
Paso 7: Diseñar la migración y el rollback
Primero, replica una carga de trabajo pequeña y no crítica en un Share Group. Compara el rendimiento, el tiempo de espera p99, los duplicados, la reentrega, la equidad de tenants y los errores posteriores. Conserva el topic original o el límite de offset reproducible. Si el ordenamiento, los efectos secundarios duplicados o los componentes en preview sufren regresiones, pausa el tráfico nuevo y vuelve al Consumer Group.
Respuesta de muestra de alta calidad
Dividiría la decisión por semántica. Los eventos que requieren orden de partición, estado de ventanas o agregación por claves permanecen en Consumer Groups; las tareas independientes, concurrentes e idempotentes pueden ser candidatas para Share Groups. Los grupos tradicionales utilizan una partición como límite de paralelismo, asignándola a un solo miembro; los Share Groups se comportan más como una cola compartida, permitiendo que varios consumidores adquieran diferentes registros de una sola topic-partition mientras retienen un límite de adquisición por partición. Antes de migrar, definiría el reconocimiento y la reentrega, las claves de idempotencia, las dead letters y las métricas de equidad de tenants, junto con bulkheads posteriores. Dado que los Share Groups están en preview en la documentación de Kafka 4.1, verificaría la compatibilidad de versiones y operativa, realizaría un despliegue canario con tenants no críticos y compararía tiempos de espera, duplicados, lag, reentrega, rendimiento por tenant y errores posteriores. Preservaría los datos reproducibles y la ruta de rollback a Consumer Groups; cualquier regresión en el ordenamiento o en los efectos secundarios pausará el tráfico y revertirá la migración.
Errores comunes
- Tratar los Share Groups simplemente como "más consumidores" ignorando la semántica de entrega y reconocimiento.
- Mover flujos con estado y ordenados por partición directamente a una cola compartida.
- Aceptar la reentrega y el procesamiento concurrente sin idempotencia.
- Observar el rendimiento total ignorando el tiempo de espera del tenant, los duplicados y la saturación posterior.
- Ignorar la compatibilidad del preview entre clientes, herramientas y actualizaciones.
- Eliminar los datos originales tras la migración, perdiendo la capacidad de reproducción y rollback.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Los Share Groups eliminan las particiones?
No. Una topic-partition sigue siendo el límite de almacenamiento y replicación. El cambio radica en que varios miembros de un share group pueden adquirir diferentes registros de una misma partición, sujetos a un límite de adquisición del clúster.
Pregunta de seguimiento 2: ¿Se puede mantener el orden para una misma clave?
No debe asumirse. Mantén el trabajo dependiente del orden en un Consumer Group, o serializa por clave en la aplicación y utiliza comprobaciones de versión para garantizar que las actualizaciones concurrentes no se sobrescriban entre sí.
Pregunta de seguimiento 3: ¿Qué sucede con un registro fallido?
Confirma según la implementación y la configuración si vuelve a estar disponible, si se retrasa o si puede reentregarse de forma concurrente. Protege los efectos secundarios con claves de idempotencia, recuentos de intentos y motivos en la dead letter.
Pregunta de seguimiento 4: ¿Cómo se evita que una ráfaga de un tenant consuma toda la capacidad?
Transporta la identidad del tenant, observa el tiempo de espera y el rendimiento por tenant, y combina cuotas en la aplicación, límites de adquisición, separación de topics o bulkheads posteriores. Convierte la equidad en objetivos con alertas.
Pregunta de seguimiento 5: ¿Por qué no migrar todo?
Las cargas de trabajo de streaming y de colas requieren diferentes garantías de ordenamiento, estado, reintentos y operaciones. Una función en preview añade riesgos de versión y de fallos, por lo que se deben clasificar las cargas de trabajo en lugar de forzar un único modelo.
Pregunta de seguimiento 6: ¿Cómo se hace un rollback de los registros ya procesados?
Conserva los eventos reproducibles y las versiones de procesamiento, detén el nuevo tráfico de Share Groups y reanuda desde el límite del Consumer Group. Compensa o reconcilia los efectos secundarios externos de forma idempotente; no los vuelvas a escribir a ciegas.