Saga Choreography with Domain Events

Happy path choreography

order-service publishes OrderPlaced. inventory-service reserves, publishes InventoryReserved. payment-service charges, publishes PaymentCaptured. shipping-service listens to PaymentCaptured. Each service owns its topic subscriptions and compensations.

Compensating transactions

Payment fails after reserve → payment-service publishes PaymentFailed → inventory-service publishes InventoryReleased. VaultCommerce uses partition key orderId so compensation events stay ordered with forward steps.

VaultCommerce rollout checklist

Before promoting changes that touch the VaultCommerce order and payment event backbone, run the staging KRaft cluster (Kafka 3.7+, Schema Registry 7.x) through a 10k events/min soak test. Compare producer request latency p99 and consumer lag per group against the pre-deploy baseline. Events chain the saga; no central brain. Document the change in the internal topic registry, attach Grafana screenshots to the change ticket, and keep an engineer on lag dashboards for 30 minutes after production rollout — roll back the service release before altering broker-level settings if lag or under-replicated partitions spike.

// VaultCommerce inventory — saga step + compensation
@KafkaListener(topics = "vaultcommerce.orders.placed.v1")
public void onOrderPlaced(OrderPlaced event) {
    try {
        inventoryService.reserve(event.orderId(), event.lines());
        publisher.publish("vaultcommerce.inventory.reserved.v1", event.orderId(),
            new InventoryReserved(event.orderId()));
    } catch (InsufficientStockException e) {
        publisher.publish("vaultcommerce.orders.rejected.v1", event.orderId(),
            new OrderRejected(event.orderId(), "OUT_OF_STOCK"));
    }
}

@KafkaListener(topics = "vaultcommerce.payments.failed.v1")
public void onPaymentFailed(PaymentFailed event) {
    inventoryService.release(event.orderId());
}