¿Qué es el patrón transactional outbox, y cómo resuelve el problema de la doble escritura entre una base de datos y un message broker?

#El problema de la doble escritura

Supongamos que un servicio de órdenes necesita hacer dos cosas cuando se coloca un pedido: persistir la orden en su base de datos, y publicar un evento OrderCreated para que inventario, facturación y notificaciones puedan reaccionar. Son dos sistemas independientes sin transacción compartida entre ellos -- una base de datos relacional no participa de la misma transacción ACID que un broker de Kafka o un exchange de RabbitMQ. Si confirmás primero la escritura en base de datos y después publicás, una caída o una interrupción del broker entre esos dos pasos deja una orden persistida de la que nadie downstream se entera jamás. Si publicás primero y confirmás después, un commit fallido deja un evento que describe una orden que no existe. Envolver ambas cosas en una transacción de dos fases (2PC) es posible en teoría pero rara vez está disponible o es deseable en la práctica -- la mayoría de los brokers no soportan XA, y los propios modos de falla de 2PC (un coordinador que muere a mitad del commit) son otro problema en sí mismos.

#La solución: hacer atómica solo una escritura, y retransmitir el resto

El patrón transactional outbox esquiva el problema en vez de resolverlo de frente: en lugar de escribir en dos sistemas, escribís en uno solo. La fila de negocio y un registro del evento a publicar entran juntos en la misma transacción local de base de datos, en una tabla outbox. Como eso es una única transacción ACID contra una única base de datos, es trivialmente atómica -- o existen ambas filas, o no existe ninguna, sin ninguna ventana intermedia. Un proceso separado, el relay (o poller), lee las filas no publicadas del outbox y las publica en el broker con su propio calendario, independiente de la petición original.

#El lado de la escritura: fila de negocio más fila de outbox, una transacción

import json
import uuid

def create_order(conn, order):
    cur = conn.cursor()
    cur.execute(
        'INSERT INTO orders (id, customer_id, total_cents, status) '
        'VALUES (%s, %s, %s, %s)',
        (order['id'], order['customer_id'], order['total_cents'], 'CREATED')
    )

    payload = json.dumps({
        'order_id': order['id'],
        'customer_id': order['customer_id'],
        'total_cents': order['total_cents'],
    })

    cur.execute(
        'INSERT INTO outbox (id, aggregate_type, aggregate_id, event_type, '
        'payload, created_at, published) '
        'VALUES (%s, %s, %s, %s, %s, now(), false)',
        (str(uuid.uuid4()), 'Order', order['id'], 'OrderCreated', payload)
    )

    conn.commit()  # una sola transaccion ACID: existen ambas filas, o ninguna
    cur.close()

#El relay: publicar, y después marcar como publicado

import time

def relay_loop(conn, producer, poll_interval_seconds=1):
    while True:
        cur = conn.cursor()
        cur.execute(
            'SELECT id, aggregate_id, event_type, payload FROM outbox '
            'WHERE published = false ORDER BY created_at ASC LIMIT 100'
        )
        rows = cur.fetchall()

        for row_id, aggregate_id, event_type, payload in rows:
            producer.produce(
                topic='order-events',
                key=aggregate_id,
                value=payload,
                headers={'event_type': event_type}
            )
            producer.flush()

            # Se marca como publicado solo despues de que el broker tiene el mensaje.
            # Un fallo entre produce() y este UPDATE causa una publicacion
            # duplicada, no una perdida -- los consumidores deben deduplicar.
            cur.execute(
                'UPDATE outbox SET published = true WHERE id = %s',
                (row_id,)
            )
            conn.commit()

        cur.close()
        time.sleep(poll_interval_seconds)

Fijate el orden de las operaciones dentro del loop: primero publicar, después marcar como publicado. Invertir ese orden reabriría exactamente el problema de doble escritura que el patrón existe para cerrar -- un fallo después de marcar como publicado pero antes de que el broker realmente tenga el mensaje descartaría el evento en silencio. Publicar primero y marcar después deja como único modo de falla una publicación duplicada, que es la razón por la cual el patrón outbox y los consumidores idempotentes están pensados para usarse juntos -- ver el patrón de tabla de deduplicación para el lado consumidor de este mismo problema.

#Dos formas de construir el relay

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Qué fallo específico previene el patrón transactional outbox?
Consultas lentas contra la tabla de ordersQue el message broker se quede sin espacio en discoQue los consumidores procesen eventos fuera de ordenUn fallo entre confirmar una escritura en base de datos y publicar el evento correspondiente, que dejaría a los dos sistemas inconsistentes
2. ¿Por qué la fila del outbox debe escribirse en exactamente la misma transacción local que la fila de negocio?
Porque ese es el único lugar donde existe atomicidad real -- una transacción de base de datos es ACID, pero no hay una transacción compartida equivalente entre una base de datos y un brokerPara reducir el tamaño de la tabla outboxPorque dos sentencias INSERT no pueden correr en la misma petición de otra formaPorque el broker lo exige
3. ¿Qué garantía de entrega le da el relay al message broker, y qué implica eso para los consumidores?
Entrega exactamente una vez, por lo que los consumidores no necesitan manejo especialEntrega at-most-once, por lo que algunos eventos simplemente pueden perderseEntrega at-least-once, por lo que los consumidores igual deben ser idempotentes, ya que un fallo después de publicar pero antes de marcar una fila como publicada causa una republicaciónNinguna garantía de entrega