Disaster Recovery for EDI stacks: RTO, RPO, patterns and runbooks

An AS4 outage at the PEPPOL operator in 2026 = pending invoices, contractual penalties, negative fiscal audit. Yet 60% of European EDI hubs have no documented and tested DR plan. Here is the methodological framework.

Why dedicated DR for EDI

Disaster recovery is an old discipline (ISO 22301 Business Continuity, ITIL, NIST SP 800-34), but EDI hubs have characteristics that justify a specific framework:

Partner contractual constraints: most partner EDI manuals (Walmart Supplier Guidelines, Stellantis OFTP2 Specs, Carrefour B2B Charter) mandate end-to-end SLAs (typically 99.5% uptime, MTTR < 4h) with financial penalties.
Fiscal compliance: an INVOIC sent but lost before archiving = potential audit problem. 10-year retention must survive any outage.
Partner asymmetry: some partners (retail, automotive) tolerate retransmissions; others (banks, fiscal e-invoicing) reject duplicates. DR must handle both.
Implicit multi-region: a European hub may ingest APAC and LATAM partners, requiring multi-region presence for latency and resilience.

Realistic RTO and RPO

RTO (Recovery Time Objective): maximum time to restore service after a disaster. RPO (Recovery Point Objective): maximum amount of data loss acceptable.

Do not confuse hub-level RTO/RPO with partner-level RTO/RPO. Typical 2026 examples by segment:

Bank ISO 20022 (correspondent payments): RTO ≤ 30 min, RPO ≤ 0 (zero loss tolerated — each pacs.008 must be preserved). Implies multi-region synchronous active-active.
Fiscal e-invoicing (Italy SdI, France PDP, Poland KSeF): RTO ≤ 1h, RPO ≤ 5 min. Invoice must be re-emitted within legal deadline.
Retail (Walmart, Carrefour) commercial EDI: RTO ≤ 4h, RPO ≤ 15 min. Partner retransmits on doubt.
Automotive OFTP2 (Stellantis, BMW): RTO ≤ 2h, RPO ≤ 5 min. DELFOR/DELJIT have fine cadences (12-24 times/day).
Healthcare HL7v2/FHIR: RTO ≤ 15 min for real-time ADT, RPO ≤ 0. Human life at stake.
IATA Cargo-XML / ONE Record cargo: RTO ≤ 1h, RPO ≤ 15 min.

Target DR topologies 2026

Four common topologies, sorted by increasing cost:

Cold standby (backup-restore)

Empty secondary region, manually triggered upon disaster. Restore from backups (S3 cross-region replicas, PostgreSQL snapshots). RTO 4-24h, RPO per backup frequency (typically 1-24h). Marginal cost. Acceptable for non-critical flows only.

Warm standby (pilot light)

Secondary region runs in minimal mode: data bricks (PostgreSQL streaming replication, Kafka mirror maker 2, cross-region Redis Cluster) are active, but compute services are at minimum scale. On switchover, scale up. RTO 30 min - 2h, RPO ≤ minutes. Moderate cost (~30% of prod). The default mode recommended for a modern EDI hub.

Hot standby (active-passive)

Secondary region at full scale, ready to take traffic, but explicit switchover (DNS, load balancer, GSLB). RTO 5-15 min, RPO ≤ 1 min. High cost (~75% of prod). Reserved for critical flows (banks, fiscal).

Active-active multi-region

All regions process simultaneously, routing by geo-DNS or global load balancer. RTO ~zero (an incident on one region does not interrupt service), RPO ≤ seconds. Very high cost (200% of prod). But introduces distributed consistency complexity — see our pattern Raft and consistent hashing. Reserved for ISO 20022 payments and extreme requirements.

In-flight messages and idempotency

The classic EDI DR trap: what happens to "in-flight" messages (ingested in the primary region but not yet processed when it dies). Three principles:

Persist early: as soon as an AS4 message is received, enrol it in the replicated queue (cross-region Kafka, RabbitMQ mirroring) before any processing. AS4 NRR (Non-Repudiation of Receipt) should only be sent to the partner after this persistence.
Idempotency everywhere: every downstream consumer must be idempotent (see Idempotent Receiver EDI and Transactional Inbox). On DR switchover, messages may be replayed — the chain must absorb them without double effect.
Traceable replay: ops tools should allow replaying a specific Kafka offset range after switchover, with reporting (how many reprocessed, how many rejected as duplicates).

Typical switchover runbook

An EDI DR runbook must be readable at 3am by an on-call engineer who did not design the system. Typical structure:

Detection: automatic criteria (primary region health-check KO > 5 min, AS4 ingress connectivity loss > 3 consecutive checks, critical partner SLO alert).
Decision: who can decide the switchover? One name + backups. Rule "if no answer in 15 min, automatic switchover".
Notification: alert pipeline to ops, critical partners (auto-mail), management.
Switchover: command sequence / Terraform / scripts to execute, in order, with validation at each step. Ideally automated via a tool (Spinnaker, Argo Workflows, AWS Systems Manager Run Command).
Verification: smoke tests (AS4 ping, EDIFACT parser, test file ingestion, partner ack returns). Explicit go/no-go criteria.
Partner communication: some partners (banks especially) must be notified of endpoint change (AS4/SFTP URL). Prepare the template email, the HR/CSM contact.
Failback: once primary region restored, replay messages received in secondary, validate consistency, gradual return.
Post-mortem: blameless, within 48-72h. RCA, timeline, corrective actions. Runbook update.

Game day: test without breaking

Untested DR does not exist. A game day is a controlled exercise simulating a disaster: abrupt primary region shutdown, Kafka broker loss, critical table corruption. Minimum schedule: 2 game days per year, at least one in "surprise" mode for the on-call team.

Methodology: inspired by Netflix Chaos Monkey and the Chaos Engineering practice (Rosenthal et al. 2020). Tools: Gremlin, AWS Fault Injection Simulator, Chaos Mesh (CNCF), Litmus (CNCF). In 2026, these tools are mature and allow injecting controlled failures in production without major operational risk.

Foundations

Standards

Flagship messages

Tools