C#: Kafka frente a RabbitMQ, qué significa confirmar progreso
Un modelo local distingue offsets por partición y acknowledgements por canal. Falla antes de confirmar y comprueba el reintento.
Luis Tavarez ·
Empezar por la semántica
Un consumidor no debería confirmar trabajo que falló. Este programa C# modela esa regla con dos adaptadores de progreso. No abre conexiones, no incluye clientes de brokers y no compara rendimiento: es un laboratorio del contrato de procesamiento.
Kafka: posición en una partición
El modelo representa un consumidor clásico de una sola partición, procesada secuencialmente. Tras procesar el offset 4, guarda 5 como siguiente posición. Confirmar una posición posterior puede saltar trabajo previo si introduces procesamiento desordenado sin controlar los huecos. Debes diseñar también rebalances y recuperación. Kafka incluye otras capacidades, como share groups; esta comparación no pretende cubrirlas.
RabbitMQ: una entrega en un canal
El segundo adaptador modela el acknowledgement individual de un delivery tag en un canal. No es un offset global. Los acknowledgements del consumidor y los publisher confirms resuelven tramos diferentes del recorrido; uno no reemplaza al otro. Streams y tipos de cola también cambian las opciones disponibles.
El fallo que se comprueba
La primera entrega termina; la segunda lanza un error antes de confirmar. El estado permanece en el primer progreso y solo avanza tras el reintento exitoso. No hay efectos de negocio duraderos en este modelo ni una promesa de exactly-once.
Decidir y completar la integración
Para un historial retenido con consumidores independientes, evalúa retención y grupos de Kafka. Para distribución y enrutamiento de tareas, evalúa exchanges, colas, reintentos y límites de RabbitMQ. Valida las capacidades concretas de cada versión. Antes de producción añade clientes reales, idempotencia persistente, límites de reintento y pruebas de caída entre guardar el efecto y confirmar.
