ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Guaranteed Delivery

The guarantee that no message is lost even if a broker crashes.

Problem

An in-memory broker loses its messages on reboot. In EDI, losing an INVOIC = losing a fiscal trace = failed audit. How to guarantee durability?

Forces

  • Performance vs durability — fsync on every write is expensive.
  • Replication vs availability — a replicated broker survives crashes but adds latency.
  • EDI carries messages with legal value — INVOIC fiscal 10 years, non-repudiable signed MDNs.
  • The producer wants a fast ACK — otherwise it retransmits (and dedup must handle).

Solution

Configure the broker (Kafka, RabbitMQ, IBM MQ) in persistent mode with replication ≥ 3, sync or async fsync per SLA, and acks=all on the producer. The broker only ACKs the message when at least N replicas have written to disk. Losing a broker (up to N-1) results in zero message loss.

EDI implementation

In EDI, recommended Kafka configuration: min.insync.replicas=2, replication.factor=3, acks=all, producer retries=infinite. On Apache MQ: persistent=true, transactional=true. For AS2/AS4: signed MDN confirmation after DB write = application-level guaranteed delivery. Typical cost: +20-30 ms latency vs in-memory.

Anti-patterns

  • acks=1 on Kafka — possible loss if the leader crashes before replication.
  • min.insync.replicas=1 — equivalent to no replication.
  • Persist the message to DB but not to the broker — inconsistency if the app crashes between the two.

Sources