¿Qué hace que un consumidor de mensajes sea idempotente, y por qué la entrega at-least-once obliga a diseñarlo así?

#Por qué la entrega 'at-least-once' es la opción por defecto

Todo message broker tiene que elegir un compromiso en torno a las garantías de entrega, y la respuesta honesta es que la 'entrega exactamente una vez' casi no existe en la práctica. Brokers como Kafka, RabbitMQ o SQS funcionan por defecto en modo at-least-once: un mensaje se reentrega hasta que el consumidor lo confirma, porque la alternativa -- confirmar antes de estar seguro de que el trabajo se realizó -- arriesga perder mensajes en silencio. En el momento en que aceptás la entrega at-least-once, el procesamiento duplicado deja de ser un caso extremo y pasa a ser una certeza para la que hay que diseñar.

La reentrega ocurre por razones mundanas e inevitables: un consumidor se cae después de confirmar su escritura en base de datos pero antes de enviar el ack; un problema de red pierde el ack en el camino de vuelta al broker; un consumer group se reequilibra a mitad de un lote y entrega el mismo offset de partición a otra instancia; un visibility timeout expira en un consumidor lento de SQS aunque el trabajo ya haya terminado. Ninguno de estos casos requiere un bug -- son el costo normal de operar sistemas distribuidos sobre una red no confiable.

#Qué significa realmente la idempotencia para un consumidor

Un consumidor idempotente produce el mismo estado final sin importar si un mensaje se procesa una vez o diez. Esa es una propiedad de la operación, no del formato del mensaje -- algunas operaciones son idempotentes de manera gratuita, y otras necesitan ingeniería deliberada para volverse seguras frente a la reentrega.

#El patrón de tabla de deduplicación

Cuando la operación en sí no es naturalmente idempotente -- el caso más común, ya que la mayoría de la lógica de negocio interesante muta el estado en relación con lo que había antes -- se necesita un límite explícito de deduplicación. La versión más confiable de esto es una tabla que registra qué ids de mensaje ya se procesaron, protegida por una restricción de unicidad, escrita en la misma transacción de base de datos que el efecto de negocio.

Ajustar líneas largas
import psycopg2
from psycopg2 import errors

def handle_message(conn, message):
    message_id = message['id']
    cur = conn.cursor()
    try:
        # La restricción de unicidad sobre message_id es todo el mecanismo:
        # una entrega duplicada falla en este insert en vez de ejecutarse dos veces.
        cur.execute(
            'INSERT INTO processed_messages (message_id, processed_at) '
            'VALUES (%s, now())',
            (message_id,)
        )
    except errors.UniqueViolation:
        conn.rollback()
        return  # entrega duplicada: ya se manejó, no-op seguro

    # El efecto de negocio y la marca de deduplicación confirman como una sola unidad atómica.
    cur.execute(
        'UPDATE accounts SET balance = balance + %s WHERE id = %s',
        (message['amount'], message['account_id'])
    )
    conn.commit()
    cur.close()

La restricción de unicidad es lo que realmente garantiza esto -- no una verificación a nivel de aplicación tipo '¿ya vi este id?', que compite consigo misma bajo consumidores concurrentes. Dos instancias de este consumidor pueden tomar el mismo mensaje reentregado al mismo tiempo; solo una gana el insert, y la otra hace rollback limpiamente.

#Dónde ubicar el límite de idempotencia

La tabla de deduplicación es la opción más sólida, pero no la única, y elegir el límite correcto depende de qué estás protegiendo.

🧠 Check your understanding
0/3 · 0/3 answered
1. Un consumidor procesa un mensaje y actualiza la base de datos, pero se cae antes de confirmar el ack al broker. ¿Qué ocurre bajo entrega at-least-once?
El broker descarta el mensaje porque ya se procesóEl broker reentrega el mensaje a un consumidorEl broker bloquea hasta que el consumidor original reinicieEl mensaje pasa de inmediato a una dead-letter queue
2. ¿Por qué el insert de la tabla de deduplicación y la actualización de negocio deben ocurrir en la misma transacción?
Para que el SQL sea más cortoPorque el estándar SQL lo exige para sentencias INSERTPara que la base de datos los ejecute en paralelo y sea más rápidoSi uno falla, ambos se revierten juntos, así nunca queda un mensaje registrado sin efecto, o un efecto sin registro
3. ¿Qué operación es naturalmente idempotente sin ningún trabajo extra?
agregar una línea a un archivo de logincrementar el balance en 10fijar un campo de estado a un valor constanteenviar un correo de confirmación