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.

Durable Subscriber

The subscriber that does not lose its place — fundamental for EDI flows that cannot be missed.

Problem

A classic publish-subscribe channel delivers only to subscribers connected at publish time. An EDI partner restarting loses messages emitted during its downtime.

Forces

  • EDI flows are asynchronous — a partner offline for 6h must not lose ORDRSPs published during that time.
  • Storing every message for every absent subscriber consumes broker storage.
  • Identifying a durable subscriber requires a stable identity (clientId).
  • Persisted messages expire per a TTL or capacity-based policy.

Solution

The subscriber registers with a stable identity (`clientId` JMS, `group.id` Kafka, AMQP durable queue). The broker tracks a per-subscriber cursor and stores unread messages until delivery. On reconnect, the broker delivers the backlog in order. Durability is explicit — a non-durable subscriber acts as an ephemeral tap.

EDI implementation

In EDI, Durable Subscriber is typical for broadcasting internal events (`InvoiceReceived`, `MDNReceived`) to several sub-systems (ERP, analytics lake, customer portal). Kafka with one `group.id` per sub-system materialises the pattern: each consumer group keeps its offset, and a sub-system restart resumes where it left off. Limits: if retention (`log.retention.hours`) is too short, a long downtime wipes the backlog.

Anti-patterns

  • ClientId randomly generated at each startup — every restart creates a new durable subscriber and duplicates the backlog.
  • Under-sized retention — a weekend offline = all messages lost.
  • Unused durable subscriber not purged — indefinite backlog accumulation.
  • Using a durable subscriber for a best-effort flow — wasted storage.

Sources