— May 16, 2026 · 9 min read

Saga vs CQRS applied to EDI flows

Saga and CQRS are patterns born in distributed microservices (Hector Garcia-Molina & Kenneth Salem, 1987; Greg Young, 2010). They apply with remarkable precision to real EDI flows — saga to orchestrate a full order, CQRS to expose a partner-status read model.

Why these patterns in an EDI context?

A full EDI flow — say a B2B order — is never an atomic transaction. An ORDERS sent to a supplier produces, over the following days or weeks, an ORDRSP (business acknowledgment), one or more DESADV (despatch advices), a RECADV (receiving advice), and finally an INVOIC (invoice). Each step lives in a different system — buyer ERP, supplier ERP, WMS, TMS, invoicing platform — without a global ACID transaction. The need: a business coordination that can traverse all those states without a distributed lock, and that can roll back (or compensate) on incident.

This need is precisely what Garcia-Molina and Salem called saga in 1987 in their SIGMOD paper "Sagas": a sequence of local transactions, each individually compensable. EDI flows were sagas before the name — the name just arrived 25 years after the practice.

A concrete EDI saga

Take a typical case: a European retailer orders 200 pallets of fresh produce from a supplier. The saga from the buyer's perspective typically looks like this:

1. State: ORDERED. The buyer ERP emits an EDIFACT ORDERS to the supplier. No compensation is possible until the supplier has answered — the business event remains reversible.
2. State: ACK_RECEIVED. The supplier returns a syntactic CONTRL then a business APERAK or ORDRSP. If the ORDRSP is positive (segment BGM+231 or BGM+233), the saga moves to CONFIRMED. If negative, the saga triggers compensation: notify procurement, look for an alternate supplier, or abandon.
3. State: SHIPPED. The supplier emits a DESADV per truck shipped. This state is reached progressively (200 pallets may leave in 3 trucks over 5 days). The saga must handle fan-out — that is typically where it gets complicated.
4. State: RECEIVED. The retailer's WMS emits a RECADV to the supplier, with possible discrepancies (missing items, damages). Significant discrepancies trigger compensation: return REQOTE, price debit, or dispute.
5. State: INVOICED. The supplier emits an INVOIC that must match the order (3-way matching ORDERS / DESADV / INVOIC). Disagreement → compensation by credit note or dispute. Agreement → payable.
6. State: PAID. The bank debit emits a REMADV to the supplier. The saga ends here, several weeks after the initial ORDERS.

This saga, seen from the process manager (EIP 312 pattern, Hohpe & Woolf 2003), is typically implemented by a persistent finite-state machine — Camunda, Temporal, or an in-house microservice on Kafka with a state machine. The saga's identifier is almost always the PO number (EDIFACT segment RFF+ON) acting as the correlation identifier.

CQRS for partner status

CQRS (Command Query Responsibility Segregation), theorised by Greg Young from 2010 onwards building on Bertrand Meyer's work, explicitly separates modification operations (commands) from read operations (queries). The core idea: optimise both paths independently, because they have different constraints — commands are transactional and rare, queries are eventually consistent and frequent.

On a multi-partner EDI hub, CQRS applies very naturally to the question: "what is the current status of my 4,000 EDI partners?" The status is derived from events emitted by the saga flows above: latest message received, latest acknowledgment, error rate over the last 30 days, average acknowledgment latency.

• Command side (write model): each EDI saga emits events ORDER_SHIPPED, INVOICE_RECEIVED, CONTRL_LATE, VALIDATION_FAILED on a Kafka or NATS bus. The write model is optimised for transactional consistency within a saga, not for cross-cutting queries.
• Query side (read model): a consumer projects these events into a denormalised read store — typically PostgreSQL with GIN indexes, or ElasticSearch. The partner_status table holds one row per partner with current indicators. Dashboards queried by product managers or support rely exclusively on this projection.
• Eventual consistency: there is a delay between the event and the projection — typically a few seconds. For dashboards, that is fine. For critical operational decisions (suspending a partner due to systemic errors), one queries the write model directly.

Combining saga and CQRS

Saga and CQRS are not competitors — they are complementary. Saga orchestrates the distributed write; CQRS exposes an optimised read over derived states.

In a modern EDI hub, the target architecture typically looks like this:

• Process Manager (Camunda, Temporal) driving N concurrent sagas, one per ORDERS-INVOIC flow.
• Event bus (Kafka) where each saga transition emits an immutable event, partitioned by partner id to guarantee per-partner ordering.
• Several projections in parallel: an "operations dashboard" projection, an "internal accounts payable" projection (how many INVOIC are awaiting payment approval?), a "partner SLA" projection (who exceeds the contractual acknowledgment threshold?).
• Immutable audit log: the Kafka bus itself serves as event store, replayable at any time to rebuild a projection or audit a flow.

When these patterns don't apply

Saga and CQRS bring non-trivial complexity. They are not justified on the following cases:

• Very simple EDI flows: single partner, single transaction (for example only inbound INVOIC invoices). A classical ETL pipeline with idempotency (EIP idempotency) is enough.
• Low volume: under a few dozen messages a day, the overhead of a process manager doesn't pay back.
• No recurring analytical query: if nobody consults a partner dashboard or SLA, CQRS is superfluous.
• Team without event-driven experience: training and tooling investment is significant. A clumsy implementation can be worse than a classical batch.

Two tools, one body of problems

Saga and CQRS are distributed-architecture patterns that find in EDI a particularly fertile ground, because EDI flows are natively distributed, multi-actor and multi-temporal. For a modern EDI hub, their combination delivers three things at once: robust orchestration of complex flows, fast projections for read needs, and audit trail by design. To dig further, see the Process Manager (EIP 312) and Correlation Identifier (EIP 163) pages, which are the elementary bricks of a well-built EDI saga.