Entrevista de ingeniería de datos: ¿cómo recuperarías mensajes atascados en un Redis Stream sin efectos secundarios duplicados?

Consigna y contexto

Las tareas de pedidos se escriben en un Redis Stream y son consumidas por varios workers en un grupo de consumidores. Un worker puede caerse después de que una API externa responda con éxito pero antes de XACK, dejando el mensaje en la Lista de Entradas Pendientes (PEL). El entrevistador te pide recuperarlo sin efectos secundarios duplicados, reintentos infinitos ni pérdidas silenciosas.

Esto evalúa la semántica de entrega en procesamiento de streams y el diseño de recuperación. XREADGROUP registra los mensajes entregados pero no confirmados en la PEL; XACK solo confirma el procesamiento ante el grupo. XAUTOCLAIM transfiere mensajes pendientes inactivos a un consumidor, pero no hace que una operación de negocio sea idempotente.

Qué evalúa el entrevistador

• Si explicas las nuevas entradas, las entradas pendientes, la PEL y la propiedad del consumidor.
• Si asignas los roles correctos a XACK, XPENDING, XCLAIM y XAUTOCLAIM.
• Si el reclamo, el efecto secundario y el acuse de recibo forman una secuencia reintentable.
• Si las claves de idempotencia, los recuentos de reintentos y un dead-letter stream gestionan los mensajes venenosos.
• Si monitoreas el tiempo de inactividad, el recuento de entregas, el tamaño de la PEL y la latencia de recuperación.

Preguntas para aclarar primero

• ¿Qué efecto secundario causa un mensaje? Los cobros, el cumplimiento (fulfillment) y las notificaciones tienen diferentes riesgos de duplicación.
• ¿Existe una clave de idempotencia y un almacén de estado autoritativo? Sin ellos, "al menos una vez" (at-least-once) no es seguro.
• ¿Cuánto tiempo puede estar inactivo un worker antes de la reclamación? El umbral debe superar el procesamiento normal y la fluctuación de red (network jitter).
• ¿Se puede recortar o eliminar el Stream? Las cargas útiles (payloads) faltantes necesitan su propia métrica y alerta.
• ¿Estás utilizando Redis 8.4 XREADGROUP CLAIM o el flujo compatible de escaneo y reclamo para versiones anteriores?

Marco de respuesta en 30 segundos

“Definiría una entrega at-least-once y mantendría la idempotencia del negocio fuera del Stream. Los workers leen con XREADGROUP, confirman el estado de negocio idempotente y solo entonces ejecutan XACK. Un worker de recuperación escanea la PEL y usa XAUTOCLAIM para entradas inactivas más allá de un umbral seguro. Limita los reintentos por recuento de entrega y tipo de error, envía mensajes venenosos a un dead-letter Stream y monitorea la PEL, el tiempo de inactividad, el recuento de reclamos, la latencia de confirmación y la supresión de duplicados.”

Respuesta detallada

Dibuja el ciclo de vida del mensaje

XADD añade una entrada al Stream. XREADGROUP la entrega y la registra en la PEL de ese consumidor. Después de que el procesamiento de negocio tiene éxito, XACK la elimina de la PEL del grupo. Si el worker se cae antes, otro worker puede reclamarla una vez cumplida la condición de inactividad.

Establece un umbral de inactividad seguro

min-idle-time para XAUTOCLAIM debe superar el percentil 99 (p99) del procesamiento normal, los reintentos razonables de dependencias y el jitter de red. De lo contrario, un worker lento pero saludable puede ser despojado del mensaje mientras aún trabaja. Escanea con el cursor devuelto hasta 0-0, luego inicia otro ciclo desde el principio porque las entradas que eran demasiado recientes pueden volverse elegibles más tarde. El umbral es un parámetro operativo, no un valor predeterminado universal de Redis.

Orden de reclamo y confirmación

Después de que un worker de recuperación reclama una entrada, verifica el estado mediante el ID del mensaje o la clave de idempotencia de negocio antes de invocar el efecto secundario externo. Escribe el resultado exitoso y el estado completado, luego ejecuta XACK. Si la escritura de estado y la llamada externa no pueden compartir una transacción, registra la intención, el resultado y una tarea de compensación. Asume que los reintentos pueden repetir una llamada; no presentes XACK como prueba de que la confirmación de negocio ocurrió.

Gestiona duplicados y reclamos concurrentes

Varios workers de recuperación pueden escanear a la vez, y los reintentos de red pueden competir con los reclamos. Aplica idempotencia en el ID de pedido, ID de solicitud de pago o una clave de negocio. Permite solo transiciones de estado válidas como de pendiente a en procesamiento y a completado. Un duplicado que lee el estado completado puede confirmarse y contarse como suprimido sin volver a cobrar. El recuento de entregas por sí solo no identifica un duplicado de negocio.

Aislar mensajes venenosos

Cada entrega incrementa un recuento de entregas. Las fallas persistentes pueden provenir de cargas útiles malformadas, una regla de negocio permanente o una dependencia no disponible. Clasifica los errores: la entrada malformada puede ir directamente a mensajes no entregados; las dependencias temporales usan backoff; las entradas que exceden un umbral de reintentos se mueven a un dead-letter Stream con el ID original, el último error, los intentos y la clave de negocio. Asigna al flujo de dead-letter un responsable y un procedimiento de compensación.

Manejar entradas recortadas o eliminadas

Si la carga útil del Stream de una entrada pendiente fue recortada o eliminada con XDEL, XAUTOCLAIM puede eliminar el ID de la PEL sin volver a entregar una carga útil. Las métricas de recuperación deben distinguir “reintentado y completado” de “la carga útil ya no existe”. Para pedidos, planifica la retención, el archivado o un almacén de cargas útiles externo para que un ID limpiado no se reporte como éxito de negocio.

Monitorear la calidad de la recuperación

Monitorea el tamaño de la PEL, la inactividad máxima, la tasa de reclamos, la distribución del recuento de entregas, la latencia de XACK, el volumen de dead-letter y los aciertos de supresión de idempotencia por grupo. Las alertas deben incluir stream, grupo, consumidor y clave de negocio. Detén un worker durante un simulacro controlado y verifica que el efecto secundario se complete una sola vez y que la entrada finalmente se confirme o se envíe a dead-letter; el éxito del comando por sí solo no es suficiente.

Respuesta modelo de alta calidad

“Utilizaría una entrega at-least-once y almacenaría el estado de idempotencia del pedido en el almacén de negocio. Un worker lee con XREADGROUP, marca el pedido en procesamiento, llama a la dependencia, escribe el resultado y el estado completado, y solo entonces envía XACK. Una caída entre esos pasos deja la entrada en la PEL.

Un worker de recuperación usa XAUTOCLAIM para entradas inactivas más allá del p99 normal más el jitter. Verifica la clave del pedido o de la solicitud de pago: las entradas completadas se confirman y se cuentan como suprimidas; las entradas no terminadas continúan a través del flujo de trabajo. Los errores malformados y permanentes no entran en bucles infinitos; los errores temporales de dependencias aplican backoff, y las entradas que superan el umbral de entrega van a un dead-letter Stream con su ID original y contexto de error.

Monitorearía la PEL, el tiempo de inactividad, el recuento de reclamos, la latencia de confirmación, los mensajes no entregados y la supresión de duplicados, y luego haría simulacros de recorte, caídas de workers y tiempos de espera de dependencias. Si XAUTOCLAIM limpia un ID cuya carga útil ha desaparecido, Redis solo indica que la carga útil no está disponible; no prueba que el pedido haya tenido éxito. La retención o el archivado deben cubrir ese caso.”

Errores comunes

• Llamar a Redis Streams exactamente una vez (exactly-once): la confirmación no incluye un efecto secundario externo → plantea at-least-once y añade idempotencia de negocio.
• Confirmar antes de completar: una caída puede perder trabajo silenciosamente → confirma después del estado de negocio exitoso.
• Configurar un tiempo de inactividad menor que el p99: se reclaman workers saludables → ajusta a partir de la distribución de procesamiento y el jitter.
• Llamar a XAUTOCLAIM indefinidamente: una entrada venenosa consume recursos → clasifica errores y usa políticas de reintento y dead-letter.
• Usar el recuento de entregas como detección de duplicados: una acción de negocio puede tener diferentes IDs de mensaje → impón una clave de negocio y una máquina de estados.
• Ignorar IDs pendientes recortados: la limpieza se reporta como éxito → alerta sobre cargas útiles faltantes y conserva un archivo externo.
• Ejecutar workers de recuperación sin un plan: los reclamos y los efectos secundarios compiten → usa estado idempotente, leases o concurrencia acotada.
• Observar solo la longitud del Stream: una PEL bloqueada es invisible → monitorea la PEL, la inactividad, la latencia de confirmación y los mensajes no entregados.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no usar XCLAIM directamente?

XCLAIM requiere que el llamador conozca qué IDs de mensaje reclamar. XAUTOCLAIM escanea la PEL por tiempo mínimo de inactividad y avanza un cursor, lo cual se adapta a los workers de recuperación. Ninguno reemplaza la idempotencia de negocio ni el aislamiento de errores.

Pregunta de seguimiento 2: ¿Un cursor 0-0 significa que no hay mensajes nuevos ni antiguos?

Significa que este escaneo llegó al final del rango del cursor de la PEL. Inicia otro ciclo desde el principio porque las entradas que antes eran demasiado recientes ahora pueden estar inactivas, y pueden haber aparecido nuevas entradas en la PEL.

Pregunta de seguimiento 3: ¿Qué pasa si el cobro tiene éxito pero XACK agota el tiempo de espera (timeouts)?

La entrada se puede entregar nuevamente. La clave de idempotencia debe hacer que el segundo intento lea el estado completado y evite un segundo cobro. Registra un resultado de negocio más un reintento de confirmación; no interpretes el tiempo de espera de la confirmación como una falla del cobro.

Pregunta de seguimiento 4: ¿Cómo eliges min-idle-time?

Usa el procesamiento p99 normal, el reintento de dependencias más largo permitido y el jitter de red como base, luego añade un margen de seguridad. Valídalo con la tasa de reclamos falsos, la latencia de recuperación y el crecimiento de la PEL. Un único número fijo no puede ajustarse a todas las tareas.

Pregunta de seguimiento 5: ¿Cuántas veces debe reintentarse una entrada malformada?

Los fallos de parseo y las violaciones inmutables de reglas de negocio suelen ir directamente a dead-letter; los fallos temporales de dependencias aplican backoff y se reintentan. Establece umbrales por tipo de error, costo y recuperabilidad, preservando el ID original, el resumen de la carga útil y el último error.

Pregunta de seguimiento 6: ¿Qué cambia con Redis 8.4 XREADGROUP CLAIM?

Combina la lectura de nuevas entradas y el reclamo de entradas pendientes inactivas en un solo comando, reduciendo el bucle multicomando requerido por versiones anteriores. La semántica de la PEL, el orden de confirmación, la idempotencia, la compensación y el manejo de mensajes venenosos siguen perteneciendo al diseño del consumidor.