La publicación de Jack Vanlightly analiza dónde debe residir la unidad de paralelismo en sistemas de mensajería como Apache Kafka, tomando como punto de partida los grupos compartidos (share groups). Aunque estos grupos permiten aceptar un registro y rechazar otro para reintento, su propósito principal no es paralelizar el consumo, sino exponer semánticas de cola sobre un log. El autor explica que el paralelismo puede ser gestionado por el broker (visible) o por el cliente (local). En el primer caso, cada unidad de paralelismo (un consumidor) requiere una conexión TCP y estado de protocolo, lo que escala mal con cargas altas. Por ejemplo, para procesar 60.000 mensajes por segundo con 1 segundo de procesamiento por mensaje se necesitarían 60.000 consumidores, y si el tiempo de procesamiento fuese de 10 segundos, se requerirían 600.000 consumidores y más de un millón de conexiones TCP. En cambio, si un solo cliente puede gestionar 1.000 mensajes en paralelo mediante hilos virtuales o tareas asíncronas, solo harían falta 60 consumidores. Vanlightly recuerda que la fórmula de paralelismo agregado es tasa por tiempo medio de procesamiento, y que la decisión de dónde ubicar la unidad de paralelismo afecta la complejidad del cliente y los costos de recursos. Menciona la biblioteca ParallelConsumer (ahora sin mantenimiento) que añadía paralelismo interno en el cliente y semánticas de cola, y sugiere que podría ser necesario un nuevo proyecto que añada paralelismo cliente-local a los grupos compartidos. El texto forma parte de una serie sobre grupos compartidos y paralelismo en Kafka.
Paralelismo visible para el broker frente al local del cliente
