Transactional Client¶

1. Nombre del Patrón¶

Nombre oficial: Transactional Client
Categoría: Messaging Endpoints (Endpoints de Mensajería)
Traducción contextual: Cliente Transaccional

2. Resumen Ejecutivo¶

Transactional Client es un patrón que garantiza que las operaciones de mensajería participen en la misma transacción que las operaciones de negocio de la aplicación, de modo que ambas se confirmen o se reviertan como una unidad atómica. Si la operación de negocio falla, el mensaje no se envía; si el envío del mensaje falla, la operación de negocio se revierte.

El problema que resuelve es uno de los más críticos en arquitecturas distribuidas: la inconsistencia entre el estado local de la aplicación (base de datos) y los mensajes publicados. Un servicio de e-commerce que guarda un pedido en su base de datos pero falla al publicar el evento OrderCreated en Kafka deja al sistema en un estado inconsistente: el pedido existe localmente pero ningún sistema downstream se entera. Inversamente, si el evento se publica pero la transacción de base de datos hace rollback, se han publicado eventos fantasma sobre un pedido que no existe.

Aparece como problema fundamental en toda arquitectura de microservicios event-driven. Es probablemente el patrón más crítico de este capítulo porque su ausencia produce los bugs más difíciles de diagnosticar: datos inconsistentes entre servicios que se manifiestan como discrepancias silenciosas en el negocio.

3. Definición Detallada¶

Propósito¶

El propósito de Transactional Client es coordinar las operaciones de persistencia local de la aplicación con las operaciones de envío de mensajes al broker, garantizando atomicidad: ambas se ejecutan o ninguna se ejecuta. Esto elimina la ventana de inconsistencia que existe cuando ambas operaciones se ejecutan independientemente.

Lógica Arquitectónica¶

El desafío fundamental es que la base de datos de la aplicación y el broker de mensajería son dos sistemas distintos con sus propios mecanismos transaccionales. Una transacción que abarque ambos requiere un protocolo de commit distribuido (2PC/XA), que es notoriamente complejo, lento y frágil. Transactional Client aborda este problema de varias formas, siendo la más moderna y robusta el Transactional Outbox Pattern.

El Transactional Outbox funciona así:

Dentro de la misma transacción de base de datos que persiste el cambio de negocio, se inserta un registro en una tabla de outbox con el mensaje a publicar.
Un proceso separado (relay/poller o CDC) lee los registros pendientes de la tabla de outbox y los publica en el broker.
Tras publicación exitosa, el registro de outbox se marca como publicado.

De esta forma, la atomicidad se resuelve mediante la transacción local de la base de datos: si la operación de negocio falla, el registro de outbox tampoco se inserta; si la operación de negocio se confirma, el registro de outbox también se confirma y eventualmente se publicará.

Principio de Diseño Subyacente¶

El principio es atomicidad local como base de consistencia eventual distribuida. En lugar de intentar una transacción distribuida (que es compleja y frágil), se garantiza atomicidad a nivel local (base de datos) y se usa un mecanismo de relay para propagar el cambio al broker. La consistencia entre sistemas se alcanza eventualmente pero de forma garantizada.

Problema Estructural que Resuelve¶

Sin Transactional Client, el código típico de un servicio que persiste un cambio y publica un evento es:

// PROBLEMA: No hay atomicidad entre DB y Kafka
orderRepository.save(order);     // ← Transacción DB
kafkaTemplate.send(event);        // ← Operación Kafka independiente

Si save() tiene éxito pero send() falla (Kafka no disponible, timeout de red, error de serialización), el pedido existe en la base de datos pero el evento nunca se publica. Los sistemas downstream (inventario, pagos, shipping) nunca se enteran del pedido.

Si send() tiene éxito pero save() falla (constraint violation, deadlock, timeout de DB), el evento se publicó para un pedido que no existe. Los sistemas downstream procesan un pedido fantasma.

Contexto en el que Emerge¶

Transactional Client emerge como necesidad inmediata en cualquier arquitectura donde un servicio necesita modificar su estado local Y notificar a otros servicios del cambio. Es decir: en prácticamente toda arquitectura de microservicios event-driven.

Por Qué No Es Trivial¶

Las soluciones aparentemente simples todas tienen problemas:

2PC/XA: coordina la transacción entre DB y broker usando un protocolo de commit distribuido. Es lento, complejo, no soportado por todos los brokers (Kafka no soporta XA), y es un single point of failure.
Enviar después de commit: save() → commit() → send(). Si send() falla después del commit, el cambio se persistió pero el evento no se publicó. Se puede reintentar, pero ¿cuántas veces? ¿Y si la aplicación se reinicia entre el commit y el send?
Enviar antes de commit: send() → save() → commit(). Si el commit falla, el evento ya se envió para un cambio que no existe.
Kafka Transactions: Kafka soporta transacciones entre topics, pero no transacciones que abarquen DB + Kafka simultáneamente.

El Transactional Outbox resuelve el problema elegantemente al reducir la atomicidad a una transacción local de DB, pero introduce su propia complejidad: la tabla de outbox, el relay process, el manejo de mensajes duplicados y el garantizar exactamente un envío por cada registro de outbox.

Relación con Sistemas Distribuidos y Mensajería¶

Transactional Client está en el corazón del problema de consistencia en sistemas distribuidos. Es una implementación práctica del principio de que en un sistema distribuido, no se puede tener atomicidad de escritura entre dos sistemas independientes sin un protocolo de coordinación. El outbox pattern es la solución pragmática que la industria ha adoptado ampliamente, combinando atomicidad local con entrega eventual garantizada.

En la práctica:

En Kafka, Transactional Client se implementa con outbox + Debezium CDC, o con outbox + poller, o con Kafka Transactions (para escenarios donde solo hay Kafka, sin DB).
En RabbitMQ, se puede usar publisher confirms + outbox, o RabbitMQ's transaction mode (que es significativamente más lento).
En Azure Service Bus, se usa outbox + relay, o Azure Functions con bindings transaccionales.
En AWS, se usa DynamoDB Streams o outbox + SQS, o Step Functions para orquestación.

4. Problema que Resuelve¶

El Problema Antes del Patrón¶

Sin Transactional Client, la operación de negocio y la publicación del evento son dos operaciones independientes que pueden fallar independientemente. Esto produce cuatro posibles resultados:

DB OK + Kafka OK: caso feliz. Todo consistente.
DB OK + Kafka FAIL: pedido existe, nadie se entera. Inconsistencia silenciosa.
DB FAIL + Kafka OK: evento publicado para pedido inexistente. Evento fantasma.
DB FAIL + Kafka FAIL: ambos fallaron. Consistente pero la operación se perdió.

Los casos 2 y 3 son los peligrosos. El caso 2 es especialmente insidioso porque es silencioso: no hay error visible, simplemente un evento que nunca se publicó.

Síntomas del Problema¶

Discrepancias entre el estado local del servicio y los datos en los servicios downstream. "El pedido existe en Order Service pero Inventory Service no lo sabe".
Eventos duplicados que se producen al reintentar envíos fallidos sin control de idempotencia.
Operaciones de negocio completadas exitosamente pero cuyos efectos downstream nunca se materializan.
Procesos de reconciliación manual entre servicios para detectar y corregir inconsistencias.
Incidentes de producción donde un servicio downstream procesa un evento para una entidad que no existe en el servicio origen.

Impacto Operativo y Arquitectónico¶

Sin Transactional Client:

La confiabilidad del sistema depende de que la red entre la aplicación y el broker nunca falle, lo cual es una asunción inválida en sistemas distribuidos.
Los procesos de reconciliación entre servicios se convierten en necesidad operacional regular, consumiendo recursos y tiempo.
La confianza del negocio en los datos del sistema se erosiona: "los números no cuadran entre sistemas" es una queja constante.
Los errores son difíciles de reproducir y diagnosticar porque dependen de condiciones de timing y disponibilidad de infraestructura.

Riesgos Si No Se Implementa Correctamente¶

Outbox sin relay: la tabla de outbox se llena pero nadie la lee. Los mensajes nunca se publican.
Relay sin idempotencia: el relay publica el mismo mensaje múltiples veces si se reinicia entre la publicación y el marcado como enviado.
Outbox sin limpieza: la tabla de outbox crece indefinidamente, afectando performance de la base de datos.
Relay con lag excesivo: el relay no puede mantener el ritmo de escritura en outbox, introduciendo latencia creciente entre la operación y la publicación.

Ejemplos Reales¶

E-commerce: un servicio de pedidos guarda el pedido en PostgreSQL y publica OrderCreated en Kafka. Sin outbox, si Kafka tiene un outage de 30 minutos, todos los pedidos creados durante ese período nunca se publican. Inventario no reserva stock, pagos no se procesan, el cliente nunca recibe confirmación.
Banca: una transferencia se registra en el core bancario pero el evento para el sistema anti-fraude no se publica. Una transferencia fraudulenta no se detecta.
Seguros: una póliza se emite pero el evento para facturación no se publica. La póliza existe pero nunca se cobra la prima.

5. Contexto de Aplicación¶

Cuándo Usarlo¶

Siempre que un servicio necesite modificar su estado local Y publicar un evento de forma atómica. Este es el caso estándar en microservicios event-driven.
Cuando la consistencia entre el estado local y los eventos publicados es un requisito de negocio (no solo técnico).
Cuando el broker de mensajería puede tener periodos de indisponibilidad y los mensajes no deben perderse.
Cuando la operación de negocio tiene efectos irreversibles (transferencia ejecutada, póliza emitida, pedido confirmado) y el evento debe publicarse con garantía.

Cuándo No Usarlo¶

Cuando la publicación del evento es "best-effort" y la pérdida ocasional de un evento es aceptable (ej: analytics, métricas, logging no crítico).
Cuando el servicio no tiene estado local y solo actúa como router o transformer de mensajes (no hay transacción local que coordinar).
Cuando se usa Event Sourcing puro donde los eventos son la fuente de verdad y no hay base de datos separada.

Precondiciones¶

El servicio tiene una base de datos transaccional (PostgreSQL, MySQL, SQL Server, Oracle, MongoDB con transacciones).
El servicio necesita publicar mensajes como efecto de operaciones de negocio que modifican estado local.
Existe un broker de mensajería (Kafka, RabbitMQ, Service Bus, SQS) al que publicar.

Restricciones¶

La latencia entre la operación de negocio y la publicación del evento está determinada por la frecuencia del relay (en el enfoque outbox + poller) o la latencia del CDC (en el enfoque outbox + CDC).
La tabla de outbox introduce overhead en cada transacción (un INSERT adicional).
El relay debe ser un proceso confiable y monitoreado.

Dependencias¶

Base de datos transaccional.
Tabla de outbox (o mecanismo equivalente).
Relay process (poller, CDC connector como Debezium, o framework como Axon).
Broker de mensajería.

Supuestos Arquitectónicos¶

La atomicidad local (dentro de la base de datos) es confiable.
La eventual consistency entre servicios es aceptable (el evento se publicará, pero puede haber un breve delay).
Los consumidores pueden manejar mensajes duplicados (at-least-once delivery).

Tipo de Sistemas Donde Aparece con Más Frecuencia¶

Microservicios event-driven en cualquier dominio.
Sistemas de e-commerce (pedidos, pagos, inventario).
Sistemas bancarios y financieros (transferencias, operaciones, movimientos).
Sistemas de seguros (emisión, siniestros, cobros).
Cualquier sistema donde la consistencia entre estado local y eventos publicados es crítica.

6. Fuerzas Arquitectónicas¶

Acoplamiento vs. Flexibilidad¶

Transactional Client desacopla la disponibilidad del broker de la operación de negocio. La operación de negocio completa exitosamente aunque el broker esté temporalmente no disponible. El outbox actúa como buffer de resiliencia. Sin embargo, la tabla de outbox acopla el schema del mensaje a la base de datos de la aplicación.

Simplicidad vs. Robustez¶

La solución simple (enviar después de commit) es frágil. La solución robusta (outbox + relay) es significativamente más compleja: tabla de outbox, relay process, idempotencia, limpieza, monitoreo. La robustez tiene un costo de implementación y operación.

Consistencia vs. Latencia¶

El outbox introduce latencia entre la operación de negocio y la publicación del evento. Con un poller cada 100ms, la latencia adicional promedio es de 50ms. Con CDC (Debezium), la latencia puede ser de decenas de milisegundos. Sin outbox (envío directo), la latencia es mínima pero la consistencia no está garantizada.

Throughput vs. Garantía de Entrega¶

Cada operación de negocio requiere un INSERT adicional en la tabla de outbox dentro de la misma transacción. A alto throughput, esto puede impactar la performance de la base de datos. Kafka Transactions proporcionan mayor throughput pero solo garantizan atomicidad entre topics de Kafka, no entre DB y Kafka.

Complejidad Operacional vs. Confiabilidad¶

Sin outbox, la operación es simple pero poco confiable. Con outbox, la confiabilidad es alta pero la operación es más compleja: hay que monitorear el relay, la tabla de outbox, el lag de publicación, y gestionar la limpieza de registros procesados.

Exactly-Once vs. At-Least-Once¶

El outbox pattern garantiza at-least-once delivery: el mensaje se publicará al menos una vez, pero podría publicarse más de una vez si el relay falla entre publicar y marcar como enviado. Exactly-once requiere idempotencia en el consumidor o Kafka Transactions end-to-end.

7. Estructura Conceptual del Patrón¶

Actores o Componentes Involucrados¶

Application Service: la lógica de negocio que ejecuta la operación y necesita publicar un evento.
Database: la base de datos transaccional de la aplicación.
Outbox Table: tabla en la base de datos que almacena los mensajes pendientes de publicar.
Relay/Dispatcher: proceso que lee la outbox table y publica los mensajes en el broker.
Message Broker: Kafka, RabbitMQ, Service Bus, etc.
Consumer: el servicio downstream que recibe y procesa el mensaje.

Flujo Lógico¶

flowchart TD
    subgraph Publicación con Outbox
        A1([Application Service]) -->|Inicia transacción DB| B1[Ejecuta operación de negocio]
        B1 -->|INSERT/UPDATE tabla de negocio| C1[Inserta registro en Outbox Table]
        C1 -->|Commit atómico| D1{Transacción exitosa?}
        D1 -->|Sí| E1[Relay detecta nuevos registros]
        E1 -->|Polling o CDC| F1[Relay lee registros pendientes]
        F1 -->|Publica cada mensaje| G1[(Broker)]
        G1 --> H1[Relay marca registros como publicados]
        H1 --> I1[Limpieza periódica de registros publicados]
    end

    subgraph Rollback
        D1 -->|No: excepción o constraint violation| J1[Rollback de la transacción]
        J1 -->|Ni operación ni outbox se persistieron| K1([No se publica nada])
    end

Responsabilidades¶

Componente	Responsabilidad
Application Service	Ejecutar lógica de negocio, insertar en outbox dentro de la misma transacción
Database	Garantizar atomicidad de la transacción local
Outbox Table	Persistir mensajes pendientes de publicación
Relay	Leer outbox, publicar al broker, gestionar idempotencia de publicación
Broker	Transportar mensajes a consumidores

Interacciones¶

Application Service → Database: transacción que incluye cambio de negocio + INSERT en outbox.
Relay → Database: lectura de registros pendientes en outbox.
Relay → Broker: publicación de mensajes.
Relay → Database: actualización de registros publicados.

Contratos Implícitos¶

La outbox table tiene un schema conocido: al menos id, aggregate_type, aggregate_id, event_type, payload, created_at, published, published_at.
El relay procesa registros en orden de creación (FIFO por aggregate para preservar causalidad).
Los consumidores manejan mensajes duplicados (at-least-once delivery).

Decisiones de Diseño Clave¶

Relay por polling vs. CDC: polling es más simple pero introduce latencia y carga de queries. CDC (Debezium) captura cambios del WAL de la DB y es más eficiente y de menor latencia.
Schema de la outbox table: ¿un campo payload JSON genérico o columnas tipadas por tipo de evento? JSON es más flexible; columnas tipadas son más eficientes para queries.
Granularidad del relay: ¿un relay por servicio, un relay compartido, o un relay integrado en la aplicación? Un relay por servicio es más simple de operar; un relay compartido centraliza la infraestructura.
Ordenamiento: ¿se garantiza orden de publicación por aggregate ID? Esto es importante para preservar la causalidad de los eventos.
Retención en outbox: ¿cuánto tiempo se conservan los registros publicados? ¿Se eliminan inmediatamente o se archivan?

8. Ejemplo Arquitectónico Detallado¶

Dominio: E-commerce — Creación Atómica de Pedido y Evento¶

Contexto del Negocio¶

Una plataforma de e-commerce procesa 100,000 pedidos diarios con picos de hasta 500 pedidos por minuto durante campañas de venta. Cada pedido creado debe notificar a: inventario (para reservar stock), pagos (para procesar el cobro), shipping (para preparar envío), notificaciones (para confirmar al cliente) y analytics (para reportes en tiempo real).

Necesidad de Integración¶

El Order Service debe garantizar que cada pedido creado tenga su evento OrderCreated publicado en Kafka. La pérdida de un evento significa que el stock no se reserva, el pago no se procesa y el cliente no recibe confirmación. Peor aún: si el pedido existe pero los servicios downstream no lo saben, la reconciliación manual es extremadamente costosa.

Sistemas Involucrados¶

Order Service: microservicio Spring Boot con PostgreSQL.
PostgreSQL: base de datos del Order Service con tablas orders y outbox_events.
Debezium: plataforma CDC que captura cambios del WAL de PostgreSQL.
Apache Kafka: broker de mensajería con topic ecommerce.orders.events.
Kafka Connect: ejecuta el Debezium connector que publica los cambios de la outbox en Kafka.
Inventory Service: consume OrderCreated para reservar stock.
Payment Service: consume OrderCreated para procesar cobro.
Notification Service: consume OrderCreated para enviar confirmación al cliente.

Restricciones Técnicas¶

La operación de crear pedido y publicar evento debe ser atómica. No se acepta pérdida de eventos.
La latencia máxima entre creación del pedido y publicación del evento debe ser menor a 1 segundo.
El sistema debe soportar 500 pedidos/minuto sin degradación.
Los consumidores deben poder manejar mensajes duplicados (at-least-once delivery).
El orden de los eventos por orderId debe preservarse (las actualizaciones de un pedido deben llegar en orden).

Flujos de Datos¶

[Order Service]
   └── PostgreSQL Transaction:
       ├── INSERT INTO orders (...)
       └── INSERT INTO outbox_events (aggregate_id, event_type, payload)

[Debezium CDC]
   └── Lee WAL de PostgreSQL
   └── Detecta INSERT en outbox_events
   └── Publica en Kafka topic: ecommerce.orders.events

[Kafka] → Inventory Service, Payment Service, Notification Service

Decisiones Arquitectónicas¶

Outbox + Debezium CDC (en lugar de outbox + poller) para minimizar latencia y no añadir carga de queries a PostgreSQL.
Tabla outbox genérica con payload JSON para soportar múltiples tipos de eventos sin modificar la tabla.
Partition key = orderId para garantizar orden de eventos por pedido.
Idempotency key en el evento para que los consumidores puedan detectar duplicados.
Outbox event routing por campo aggregate_type para dirigir eventos a topics específicos si fuera necesario.

Riesgos y Mitigaciones¶

Riesgo	Mitigación
Debezium CDC falla y los eventos se acumulan en outbox	Monitoreo de lag de Debezium, alertas cuando el lag supera 5 segundos
Mensaje duplicado enviado si Debezium se reinicia	Idempotency key en cada evento, consumidores implementan deduplicación
Outbox table crece indefinidamente	Job de limpieza que elimina registros publicados hace más de 7 días
PostgreSQL WAL crece por retención de Debezium	Configurar `wal_level=logical` con retention adecuado
Esquema de outbox cambia y rompe Debezium	Versionado del schema de outbox, testing de CDC en CI/CD

9. Desarrollo Paso a Paso del Ejemplo¶

Paso 1: Creación de la Tabla Outbox¶

CREATE TABLE outbox_events (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregate_type  VARCHAR(100) NOT NULL,
    aggregate_id    VARCHAR(100) NOT NULL,
    event_type      VARCHAR(100) NOT NULL,
    payload         JSONB NOT NULL,
    created_at      TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    published       BOOLEAN DEFAULT FALSE,
    published_at    TIMESTAMP WITH TIME ZONE
);

CREATE INDEX idx_outbox_unpublished ON outbox_events (created_at)
    WHERE published = FALSE;

Paso 2: Operación de Negocio con Outbox¶

@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final OutboxRepository outboxRepository;
    private final OrderEventMapper mapper;

    @Transactional
    public OrderResult createOrder(CreateOrderRequest request) {
        // 1. Crear y persistir el pedido
        Order order = Order.create(request);
        order.validate();
        orderRepository.save(order);

        // 2. Insertar evento en outbox (misma transacción)
        OrderCreatedEvent event = mapper.toOrderCreatedEvent(order);
        OutboxEvent outboxEvent = OutboxEvent.builder()
            .aggregateType("Order")
            .aggregateId(order.getId().toString())
            .eventType("OrderCreated")
            .payload(JsonSerializer.serialize(event))
            .build();
        outboxRepository.save(outboxEvent);

        // 3. Ambos se confirman o se revierten juntos
        return OrderResult.success(order.getId());
    }
}

Paso 3: Configuración de Debezium CDC¶

{
  "name": "outbox-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "order-db",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "${DEBEZIUM_PASSWORD}",
    "database.dbname": "orders",
    "table.include.list": "public.outbox_events",
    "transforms": "outbox",
    "transforms.outbox.type": "io.debezium.transforms.outbox.EventRouter",
    "transforms.outbox.table.field.event.id": "id",
    "transforms.outbox.table.field.event.key": "aggregate_id",
    "transforms.outbox.table.field.event.type": "event_type",
    "transforms.outbox.table.field.event.payload": "payload",
    "transforms.outbox.route.by.field": "aggregate_type",
    "transforms.outbox.route.topic.replacement": "ecommerce.${routedByValue}.events"
  }
}

El Debezium Outbox Event Router transforma automáticamente los registros de la outbox table en mensajes de Kafka, usando aggregate_id como partition key y aggregate_type para determinar el topic destino.

Paso 4: Consumidor Idempotente¶

Dado que el outbox + CDC proporciona at-least-once delivery, los consumidores implementan idempotencia:

@KafkaListener(topics = "ecommerce.Order.events")
public void handleOrderCreated(OrderCreatedEvent event) {
    // Verificar si ya se procesó este evento
    if (processedEventsRepository.exists(event.getEventId())) {
        log.info("Event {} already processed, skipping", event.getEventId());
        return;
    }

    // Procesar evento
    inventoryService.reserveStock(event.getOrderId(), event.getItems());

    // Registrar como procesado
    processedEventsRepository.save(event.getEventId());
}

Paso 5: Limpieza de Outbox¶

Un scheduled job limpia los registros publicados:

@Scheduled(cron = "0 0 2 * * *") // Diariamente a las 2:00 AM
public void cleanPublishedOutboxEvents() {
    LocalDateTime cutoff = LocalDateTime.now().minusDays(7);
    int deleted = outboxRepository.deletePublishedBefore(cutoff);
    log.info("Cleaned {} published outbox events older than {}", deleted, cutoff);
}

Paso 6: Monitoreo del Pipeline¶

Se configuran métricas y alertas para el pipeline outbox → CDC → Kafka:

Outbox depth: número de registros pendientes en outbox (published = false). Si crece, el relay no está funcionando.
CDC lag: latencia de Debezium medida como la diferencia entre created_at del registro y el timestamp de publicación en Kafka.
Consumer lag: mensajes pendientes de procesamiento por cada consumer group.

Manejo de Errores¶

Debezium falla: los registros se acumulan en la outbox table. Cuando Debezium se recupera, procesa todos los pendientes desde el último offset del WAL.
Kafka no disponible: Debezium entra en error y reintenta automáticamente. Los registros se acumulan en outbox.
PostgreSQL WAL lleno: si Debezium está detenido mucho tiempo, el WAL puede crecer excesivamente. Se configura max_wal_size y alertas de espacio de WAL.
Duplicado en Kafka: posible si Debezium se reinicia después de publicar pero antes de confirmar el offset. Los consumidores manejan duplicados.

10. Diagrama Técnico del Patrón¶

Código Python con `diagrams`¶

GeneralAWSAzure

Ver / Copiar código de los diagramas

GeneralAWSAzure

from diagrams import Diagram, Cluster, Edge
from diagrams.programming.language import Java
from diagrams.onprem.queue import Kafka
from diagrams.onprem.database import PostgreSQL
from diagrams.generic.compute import Rack
from diagrams.programming.framework import Spring

with Diagram("Transactional Client - E-commerce Outbox Pattern", show=False, direction="LR"):

    with Cluster("Order Service"):
        order_service = Spring("OrderService\n(@Transactional)")

        with Cluster("PostgreSQL"):
            orders_table = PostgreSQL("orders\ntable")
            outbox_table = PostgreSQL("outbox_events\ntable")

    with Cluster("CDC Pipeline"):
        debezium = Rack("Debezium\nCDC Connector")
        kafka_connect = Rack("Kafka Connect\n(Outbox Router)")

    with Cluster("Kafka Cluster"):
        topic = Kafka("ecommerce.Order\n.events")

    with Cluster("Consumers"):
        inventory = Java("Inventory\nService")
        payments = Java("Payment\nService")
        notifications = Java("Notification\nService")

    # Transaction boundary
    order_service >> Edge(label="INSERT order\n(same TX)") >> orders_table
    order_service >> Edge(label="INSERT event\n(same TX)") >> outbox_table

    # CDC pipeline
    outbox_table >> Edge(label="WAL\ncapture", style="bold") >> debezium
    debezium >> Edge(label="route") >> kafka_connect
    kafka_connect >> Edge(label="publish") >> topic

    # Consumers
    topic >> Edge(label="consume") >> inventory
    topic >> Edge(label="consume") >> payments
    topic >> Edge(label="consume") >> notifications

from diagrams import Diagram, Cluster, Edge
from diagrams.aws.compute import Lambda, ECS
from diagrams.aws.database import RDS
from diagrams.aws.integration import SNS, SQS
from diagrams.aws.migration import DMS


with Diagram("Transactional Client - E-commerce Outbox Pattern (AWS)", show=False, direction="LR"):

    with Cluster("Order Service"):
        order_service = ECS("OrderService\n(Transactional)")

        with Cluster("RDS PostgreSQL"):
            orders_table = RDS("orders\ntable")
            outbox_table = RDS("outbox_events\ntable")

    with Cluster("CDC Pipeline"):
        dms = DMS("DMS CDC\nCapture")

    with Cluster("Fan-out"):
        topic = SNS("order-events\nTopic")

    with Cluster("Consumers"):
        inv_q = SQS("Inventory\nQueue")
        inventory = Lambda("Inventory\nService")
        pay_q = SQS("Payment\nQueue")
        payments = Lambda("Payment\nService")
        notif_q = SQS("Notification\nQueue")
        notifications = Lambda("Notification\nService")

    # Transaction boundary
    order_service >> Edge(label="INSERT order\n(same TX)") >> orders_table
    order_service >> Edge(label="INSERT event\n(same TX)") >> outbox_table

    # CDC pipeline
    outbox_table >> Edge(label="WAL\ncapture", style="bold") >> dms
    dms >> Edge(label="publish") >> topic

    # Consumers (SNS fan-out to SQS)
    topic >> Edge(label="fan-out") >> inv_q >> inventory
    topic >> Edge(label="fan-out") >> pay_q >> payments
    topic >> Edge(label="fan-out") >> notif_q >> notifications

from diagrams import Diagram, Cluster, Edge
from diagrams.azure.compute import FunctionApps
from diagrams.azure.database import CosmosDb, DatabaseForPostgresqlServers
from diagrams.azure.integration import ServiceBus

with Diagram("Transactional Client - E-commerce Outbox Pattern (Azure)", show=False, direction="LR"):

    with Cluster("Order Service"):
        order_service = FunctionApps("OrderService\n(Container App)")

        with Cluster("Cosmos DB (Change Feed as Outbox)"):
            orders_container = CosmosDb("orders\ncontainer")

    with Cluster("Change Feed Pipeline"):
        change_feed = FunctionApps("Change Feed\nTrigger Function")

    with Cluster("Azure Service Bus"):
        topic = ServiceBus("order-events\nTopic")

    with Cluster("Consumers (Functions)"):
        inventory = FunctionApps("Inventory\nFunction")
        payments = FunctionApps("Payment\nFunction")
        notifications = FunctionApps("Notification\nFunction")

    # Transaction boundary - Cosmos DB transactional batch
    order_service >> Edge(label="upsert order\n(transactional batch)") >> orders_container

    # Change Feed pipeline
    orders_container >> Edge(label="Change Feed\n(automatic)", style="bold") >> change_feed
    change_feed >> Edge(label="publish") >> topic

    # Consumers
    topic >> Edge(label="subscription") >> inventory
    topic >> Edge(label="subscription") >> payments
    topic >> Edge(label="subscription") >> notifications

Explicación del Diagrama¶

El diagrama muestra el flujo completo del Transactional Outbox Pattern:

Order Service: dentro de una misma transacción (@Transactional), inserta tanto el pedido como el evento en PostgreSQL. Si alguno falla, ambos hacen rollback.
PostgreSQL: contiene tanto la tabla de negocio (orders) como la tabla de outbox (outbox_events). La transacción local garantiza atomicidad.
CDC Pipeline: Debezium captura los INSERTs en la outbox table leyendo el WAL de PostgreSQL. El Outbox Event Router de Debezium transforma los registros en mensajes de Kafka con el topic, key y payload correctos.
Kafka: recibe los mensajes y los distribuye a los consumer groups.
Consumers: Inventory, Payment y Notification services procesan los eventos con idempotencia.

Correspondencia Patrón ↔ Diagrama¶

Concepto del Patrón	Componente del Diagrama
Transactional Client	OrderService (@Transactional)
Local Transaction	INSERT orders + INSERT outbox (same TX)
Outbox Table	outbox_events table
Relay/Dispatcher	Debezium CDC + Kafka Connect
Message Broker	Kafka cluster
Consumers	Inventory, Payment, Notification Services

11. Beneficios¶

Impacto Técnico¶

Atomicidad garantizada: la operación de negocio y la publicación del evento son atómicas. No hay ventana de inconsistencia entre DB y broker.
Resiliencia ante fallos del broker: si Kafka está temporalmente no disponible, los pedidos siguen creándose. Los eventos se acumulan en la outbox y se publican cuando el broker se recupera.
Orden preservado: el outbox preserva el orden de creación de eventos por aggregate, y el CDC los publica en ese orden. Esto garantiza causalidad.
Auditoría de eventos: la outbox table es un registro auditable de todos los eventos publicados, con timestamp de creación y publicación.

Impacto Organizacional¶

Confianza en los datos: los equipos de negocio pueden confiar en que si una operación se completó, el evento correspondiente se publicó (o se publicará).
Eliminación de reconciliación manual: no se necesitan procesos de reconciliación para detectar eventos perdidos.
Diseño desacoplado: los equipos pueden diseñar sus servicios asumiendo que los eventos llegan de forma confiable.

Impacto Operacional¶

Reducción de incidentes: los incidentes por "evento perdido" o "evento fantasma" se eliminan.
Monitoreo claro: el lag de la outbox es una métrica directa de la salud del pipeline de eventos.
Recovery automático: cuando el broker se recupera de un outage, los eventos pendientes se publican automáticamente sin intervención manual.

Beneficios de Mantenibilidad y Evolución¶

Patrón estandarizado: el outbox pattern es bien conocido y documentado. Librerías como Debezium, Axon, MassTransit y NServiceBus lo implementan out-of-the-box.
Extensibilidad: añadir nuevos tipos de eventos requiere solo un nuevo INSERT en la outbox; no se necesita modificar la infraestructura del relay.

12. Desventajas y Riesgos¶

Complejidad Añadida¶

Infraestructura adicional: la outbox table, el CDC connector (Debezium), Kafka Connect, y el monitoreo del pipeline son componentes adicionales que deben desplegarse, configurarse y operarse.
Latencia adicional: el pipeline outbox → CDC → Kafka introduce latencia (típicamente 50ms-500ms) respecto al envío directo.
Esquema de outbox: la tabla de outbox debe diseñarse, migrarse y mantenerse. Cambios en el schema de outbox pueden afectar al CDC connector.

Riesgos de Mal Uso¶

At-least-once sin idempotencia en consumidores: el outbox pattern garantiza at-least-once delivery. Si los consumidores no manejan duplicados, se producirán efectos duplicados (doble cobro, doble reserva de stock).
Outbox como cola: usar la outbox table como cola de mensajes de uso general (en lugar de como buffer transitorio para CDC) degrada la performance de la base de datos.
Relay lento: si el relay (poller o CDC) no puede mantener el ritmo de escritura en outbox, la latencia de publicación crece progresivamente.

Sobreingeniería¶

Implementar outbox pattern para eventos no críticos (analytics, logging) donde la pérdida ocasional es aceptable.
Usar 2PC/XA cuando outbox pattern sería suficiente y más simple de operar.
Construir un relay propio cuando Debezium proporciona uno robusto y probado.

Costos de Operación¶

Debezium requiere operación continua: monitoreo de snapshots, gestión de slots de replicación lógica en PostgreSQL, actualización de versiones.
La outbox table necesita limpieza periódica para evitar crecimiento descontrolado.
El WAL de PostgreSQL crece proporcionalmente a la actividad de la outbox, lo que requiere sizing adecuado del almacenamiento.

Anti-Patterns Relacionados¶

Send-and-Pray: enviar el mensaje directamente al broker sin outbox y confiar en que "normalmente funciona". El primer outage del broker produce inconsistencias.
Dual Write: escribir en la base de datos y en el broker como dos operaciones independientes, esperando que ambas tengan éxito. Es exactamente el problema que el outbox resuelve.
Outbox Abuse: almacenar datos de negocio en la outbox table o usarla para queries de negocio. La outbox es un mecanismo transitorio de publicación, no una tabla de negocio.

13. Relación con Otros Patrones¶

Patrones Complementarios¶

Messaging Gateway: el gateway usa Transactional Client internamente. La aplicación invoca el gateway, y el gateway implementa el outbox.
Idempotent Receiver: necesario en el consumidor porque el outbox + CDC proporciona at-least-once delivery, lo que puede producir duplicados.
Messaging Mapper: el mapper convierte el objeto de dominio al payload que se almacena en la outbox table.

Patrones que Suelen Aparecer Antes o Después¶

Event Sourcing: una alternativa al outbox pattern. En Event Sourcing, los eventos son la fuente de verdad y se persisten directamente. No se necesita outbox porque los eventos ya están en la base de datos como entidades de primera clase.
Saga / Process Manager: cuando la operación involucra múltiples servicios en una secuencia, el Transactional Client garantiza que cada paso publique su evento de forma confiable.

Combinaciones Comunes¶

Transactional Client + Debezium CDC + Kafka: la combinación más popular en la industria actualmente. Debezium captura los cambios del WAL y los publica en Kafka automáticamente.
Transactional Client + Polling Relay: alternativa más simple sin CDC. Un scheduled job lee la outbox y publica los mensajes pendientes. Mayor latencia pero menor infraestructura.

Diferencias con Patrones Similares¶

vs. Event Sourcing: Event Sourcing elimina la necesidad de outbox porque los eventos son el estado principal. Transactional Client es necesario cuando hay un modelo de estado tradicional (tablas relacionales) además de los eventos.
vs. Saga Pattern: Saga coordina múltiples servicios; Transactional Client garantiza atomicidad dentro de un solo servicio. Son complementarios: cada paso de una saga usa Transactional Client para garantizar su publicación.

Encaje en un Flujo Mayor de Integración¶

Transactional Client se sitúa en la frontera de salida de cada microservicio, garantizando que los eventos producidos como efecto de operaciones de negocio se publiquen de forma confiable. Es la base de confiabilidad sobre la que se construyen flujos de integración más complejos (sagas, event choreography, CQRS).

14. Relevancia Actual del Patrón¶

Evaluación: Relevancia Alta (Crítica)¶

Argumentación¶

Transactional Client, implementado como Transactional Outbox, es probablemente el patrón más importante para la confiabilidad de arquitecturas de microservicios event-driven. Su relevancia no solo se mantiene sino que ha aumentado significativamente con la adopción masiva de arquitecturas event-driven.

A favor de la vigencia:

Toda arquitectura de microservicios event-driven necesita resolver el problema de atomicidad entre estado local y eventos publicados. El outbox pattern es la solución estándar de la industria.
Debezium ha madurado como herramienta de CDC y hace que la implementación sea significativamente más accesible que hace cinco años.
Los cloud providers ofrecen servicios gestionados que facilitan el patrón: DynamoDB Streams, Azure Cosmos DB Change Feed, AWS EventBridge Pipes.
Frameworks como MassTransit, NServiceBus y Axon incluyen implementaciones out-of-the-box del outbox pattern.

Evolución del patrón:

El Outbox Pattern ha evolucionado de un concepto teórico a una práctica estándar con tooling maduro.
Kafka Transactions proporcionan una alternativa para escenarios específicos (consume-transform-produce dentro de Kafka).
Los event stores (EventStoreDB, Axon Server) eliminan la necesidad de outbox al hacer de los eventos la fuente de verdad.

Cómo Se Implementa Hoy¶

Debezium Outbox Event Router: la implementación más popular. Debezium captura INSERTs en la outbox table y los publica en Kafka con routing configurable.
Spring Modulith Events: publicación transaccional de eventos de dominio con outbox integrado.
MassTransit Transactional Outbox: outbox integrado en MassTransit para .NET con soporte para Entity Framework y MongoDB.
Axon Framework: integra outbox y event publishing como parte de su gestión del ciclo de vida de aggregates.

15. Implementación en Arquitecturas Modernas¶

Apache Kafka con Debezium¶

La combinación más extendida. Debezium lee el WAL de PostgreSQL/MySQL, captura INSERTs en la outbox table, y usa el Outbox Event Router para publicar en Kafka topics. La configuración es declarativa y el mantenimiento es operacional (no requiere código de relay propio). Kafka Transactions complementan para escenarios de consume-transform-produce dentro de Kafka.

Azure Integration¶

Azure SQL + Azure Functions: la outbox se lee con un Azure Function timer trigger que publica en Azure Service Bus o Event Hubs.
Azure Cosmos DB Change Feed: Cosmos DB proporciona change feed nativo que actúa como CDC sin herramientas adicionales. Los cambios en la outbox collection se capturan automáticamente y se publican en Event Hubs.
Azure Event Grid + Service Bus: para escenarios donde los eventos se publican en Event Grid desde Azure Functions.

AWS Integration¶

DynamoDB Streams: DynamoDB proporciona streams nativos de cambios. Los INSERTs en la outbox table se capturan como DynamoDB Stream events y se procesan con Lambda para publicar en SQS/SNS/EventBridge.
RDS + Debezium: para bases de datos relacionales en AWS, Debezium en ECS/EKS captura WAL de RDS PostgreSQL y publica en MSK (Managed Kafka).
EventBridge Pipes: AWS EventBridge Pipes conecta fuentes (DynamoDB Streams, SQS) con destinos (EventBridge, Step Functions) con filtering y transformation integrados.

Spring Boot / Spring Framework¶

Spring Data JPA + Outbox table: el outbox se implementa como un @Entity JPA que se persiste en la misma transacción.
Spring Modulith: proporciona @ApplicationModuleListener y event publication log que implementan outbox transparentemente.
Spring Cloud Stream + Kafka Transactions: para escenarios de procesamiento de streams con exactly-once semantics.

.NET / MassTransit¶

MassTransit proporciona un Transactional Outbox integrado que soporta Entity Framework Core y MongoDB. La configuración es declarativa y el relay se ejecuta dentro del mismo proceso o como hosted service separado.

16. Consideraciones de Gobierno y Operación¶

Observabilidad¶

Métricas clave: outbox depth (registros pendientes), outbox throughput (registros publicados/segundo), end-to-end latency (tiempo desde INSERT en outbox hasta publicación en broker), relay lag, consumer lag.
Health checks: verificar que el relay está activo, que el outbox depth no crece, que el CDC connector está en estado RUNNING.
Alertas: outbox depth supera umbral (relay no funciona), latencia end-to-end supera SLA, CDC connector en estado FAILED.

Tracing¶

Cada registro de outbox debe incluir un trace ID que se propaga al mensaje publicado en el broker.
El trace ID permite correlacionar la operación de negocio original con el evento publicado y su procesamiento en consumidores.

Monitoreo¶

Dashboard de outbox: profundidad, throughput, latencia, errores.
Dashboard de CDC: estado del connector, offset del WAL, lag.
Dashboard de consumidores: consumer lag por grupo, tasa de procesamiento, errores.

Versionado¶

El schema de la outbox table debe versionarse. Cambios en el schema (nuevas columnas, cambios de tipo) deben coordinarse con el CDC connector.
Los payloads en la outbox pueden incluir schemaVersion para que los consumidores manejen múltiples versiones.

Seguridad¶

La outbox table contiene payloads de eventos que pueden incluir datos sensibles. Las políticas de acceso a la base de datos deben proteger la outbox table.
El usuario de Debezium necesita acceso de lectura al WAL y a la outbox table. Debe ser un usuario con los mínimos privilegios necesarios.
La comunicación entre Debezium y Kafka debe estar protegida con SSL/SASL.

Manejo de Errores¶

CDC connector falla: alertar inmediatamente. Los registros se acumulan en outbox. Al reiniciar, Debezium retoma desde el último offset del WAL.
Kafka no disponible: Debezium entra en modo de retry. Los registros se acumulan en outbox y WAL.
Outbox table llena: si la base de datos está llena, las transacciones de negocio también fallan. Monitorear espacio de tabla.

Retries¶

El relay (Debezium) implementa retries automáticos con backoff configurable.
Si un mensaje no puede publicarse después de N retries, se debe alertar y posiblemente mover a dead-letter.

Dead-Lettering¶

Los registros de outbox que no pueden publicarse después de múltiples intentos deben marcarse como "failed" con el motivo del error.
Un proceso de revisión periódica examina los registros failed para determinar si pueden republicarse o requieren intervención manual.

Idempotencia¶

El outbox incluye un event_id (UUID) que sirve como idempotency key para los consumidores.
Si el relay publica el mismo registro dos veces, el consumidor detecta el duplicado por el event_id y lo ignora.

Performance¶

El INSERT en outbox dentro de la transacción añade latencia a la operación de negocio (típicamente <1ms para un INSERT simple).
El CDC introduce latencia de 10ms-500ms dependiendo de la configuración.
La limpieza de outbox debe ejecutarse en horarios de baja carga para no impactar la performance de la base de datos.

Escalabilidad¶

El outbox pattern escala horizontalmente si la base de datos se particiona o se usa sharding.
Debezium puede escalarse ejecutando múltiples connectors contra diferentes particiones o tablas.
En Kafka, el throughput escala con el número de particiones del topic destino.

17. Errores Comunes¶

Dual Write sin Outbox¶

El error más frecuente y más grave: escribir en la base de datos y enviar al broker como dos operaciones independientes. Funciona en condiciones normales pero falla inevitablemente cuando el broker tiene un outage, la red tiene un glitch, o la aplicación se reinicia entre ambas operaciones.

Outbox sin Relay¶

Implementar la outbox table e insertar registros pero no implementar (o no activar) el relay que los publica. Los registros se acumulan indefinidamente sin ser publicados.

Consumidores sin Idempotencia¶

El outbox + CDC proporciona at-least-once delivery. Si los consumidores no verifican si un evento ya fue procesado, los duplicados producen efectos dobles: doble cobro, doble envío, doble reserva de inventario.

Orden No Preservado¶

Si el relay no preserva el orden de los registros de outbox por aggregate ID, los consumidores pueden recibir OrderShipped antes de OrderCreated. El relay debe garantizar FIFO por aggregate.

Outbox sin Limpieza¶

La outbox table crece con cada operación de negocio. Sin limpieza periódica, la tabla alcanza millones de registros, degradando la performance de la base de datos y del CDC connector.

Ignorar el Lag del CDC¶

Si el CDC connector tiene lag creciente (publica registros cada vez más tarde), la latencia end-to-end aumenta progresivamente. Esto puede ser invisible sin monitoreo adecuado y puede manifestarse como "los servicios downstream están desincronizados" horas después.

Usar Outbox como Cola de Mensajes¶

Diseñar la aplicación para que consulte directamente la outbox table como fuente de mensajes (en lugar de consumir del broker) pervierte el propósito de la outbox. La outbox es un buffer transitorio, no una cola de consumo.

18. Conclusión Técnica¶

Transactional Client, implementado como Transactional Outbox Pattern, es la solución estándar de la industria para el problema de atomicidad entre estado local y eventos publicados en arquitecturas de microservicios. Su importancia no puede subestimarse: sin este patrón, toda arquitectura event-driven tiene un defecto fundamental de confiabilidad.

Para un arquitecto de sistemas modernos, las directrices son:

Implementar outbox pattern siempre que un servicio modifique estado local y publique eventos. No existe escenario de negocio crítico donde el "dual write" sin outbox sea aceptable.
Preferir CDC (Debezium) sobre polling para minimizar latencia y carga en la base de datos. Debezium Outbox Event Router proporciona routing, serialización y publicación out-of-the-box.
Exigir idempotencia en todos los consumidores. El outbox proporciona at-least-once delivery; los duplicados son inevitables y deben manejarse.
Monitorear el pipeline end-to-end: outbox depth, CDC lag, consumer lag. La salud del pipeline de eventos es tan crítica como la salud de la base de datos.
Limpiar la outbox periódicamente para evitar crecimiento descontrolado.

En el contexto del e-commerce del ejemplo, el outbox pattern garantiza que cada uno de los 100,000 pedidos diarios tenga su evento OrderCreated publicado en Kafka, sin importar interrupciones transitorias del broker. Inventario reserva stock, pagos se procesan, y los clientes reciben confirmación — todo con la garantía de que ningún evento se pierde. El costo es la complejidad del pipeline CDC, pero el beneficio es la eliminación completa de una clase de bugs que produce las incidencias de producción más difíciles de diagnosticar: la desincronización silenciosa entre servicios.

Transactional Client¶

1. Nombre del Patrón¶

2. Resumen Ejecutivo¶

3. Definición Detallada¶

Propósito¶

Lógica Arquitectónica¶

Principio de Diseño Subyacente¶

Problema Estructural que Resuelve¶

Contexto en el que Emerge¶

Por Qué No Es Trivial¶

Relación con Sistemas Distribuidos y Mensajería¶

4. Problema que Resuelve¶

El Problema Antes del Patrón¶

Síntomas del Problema¶

Impacto Operativo y Arquitectónico¶

Riesgos Si No Se Implementa Correctamente¶

Ejemplos Reales¶

5. Contexto de Aplicación¶

Cuándo Usarlo¶

Cuándo No Usarlo¶

Precondiciones¶

Restricciones¶

Dependencias¶

Supuestos Arquitectónicos¶

Tipo de Sistemas Donde Aparece con Más Frecuencia¶

6. Fuerzas Arquitectónicas¶

Acoplamiento vs. Flexibilidad¶

Simplicidad vs. Robustez¶

Consistencia vs. Latencia¶

Throughput vs. Garantía de Entrega¶

Complejidad Operacional vs. Confiabilidad¶

Exactly-Once vs. At-Least-Once¶

7. Estructura Conceptual del Patrón¶

Actores o Componentes Involucrados¶

Flujo Lógico¶

Responsabilidades¶

Interacciones¶

Contratos Implícitos¶

Decisiones de Diseño Clave¶

8. Ejemplo Arquitectónico Detallado¶

Dominio: E-commerce — Creación Atómica de Pedido y Evento¶

Contexto del Negocio¶

Necesidad de Integración¶

Sistemas Involucrados¶

Restricciones Técnicas¶

Flujos de Datos¶

Decisiones Arquitectónicas¶

Riesgos y Mitigaciones¶

9. Desarrollo Paso a Paso del Ejemplo¶

Paso 1: Creación de la Tabla Outbox¶

Paso 2: Operación de Negocio con Outbox¶

Paso 3: Configuración de Debezium CDC¶

Paso 4: Consumidor Idempotente¶

Paso 5: Limpieza de Outbox¶

Paso 6: Monitoreo del Pipeline¶

Manejo de Errores¶

10. Diagrama Técnico del Patrón¶

Código Python con diagrams¶

Explicación del Diagrama¶

Correspondencia Patrón ↔ Diagrama¶

11. Beneficios¶

Impacto Técnico¶

Impacto Organizacional¶

Impacto Operacional¶

Beneficios de Mantenibilidad y Evolución¶

12. Desventajas y Riesgos¶

Complejidad Añadida¶

Riesgos de Mal Uso¶

Sobreingeniería¶

Costos de Operación¶

Anti-Patterns Relacionados¶

13. Relación con Otros Patrones¶

Patrones Complementarios¶

Patrones que Suelen Aparecer Antes o Después¶

Combinaciones Comunes¶

Diferencias con Patrones Similares¶

Encaje en un Flujo Mayor de Integración¶

14. Relevancia Actual del Patrón¶

Evaluación: Relevancia Alta (Crítica)¶

Argumentación¶

Código Python con `diagrams`¶