— May 16, 2026 · 13 min read

ISGo EDI architecture 2026: event-driven, polyglot, observable

How does one build a modern EDI hub in 2026, without replicating the monolithic ESBs of the 2010s nor getting lost in microservice overkill? Here is the ISGo reference architecture: multi-protocol ingest, event-driven pipeline, canonical event store, per-partner state machines, multi-tenant observability. A synthesis of Hohpe-Woolf, Kleppmann, Newman principles applied to a domain where asynchronicity and audit weigh more than sub-second latency.

Layer 1: multi-protocol ingest

The ingest layer receives incoming messages from all partner protocols. Dedicated adapters normalise the entry into a single internal format before any durable write:

• AS2 gateway (RFC 4130/6362): S/MIME reception, MDN verification, signed payload persistence for audit.
• AS4 gateway (OASIS ebMS 3.0 / PEPPOL eDelivery): ebMS reception, signed receipt verification, archival of message + receipt couple.
• OFTP2 connector (RFC 5024): for automotive and ENX partners, with EERP management.
• SFTP/FTPS pollers: for legacy partners, in Polling Consumer pattern (EIP §494).
• HTTP/REST endpoints: for modern APIs (public portal invoices, PEPPOL webhooks).

Each adapter emits, upon reception, an EdiMessageReceived event on the internal bus (Kafka topic edi.ingress.raw), carrying correlation ID, payload hash, partner metadata and timestamp. The raw payload is stored in an immutable object store (S3 with Object Lock for tax unalterability).

Layer 2: normalisation pipeline

The normalisation pipeline is the transformation chain that moves a raw message (EDIFACT, X12, UBL, proprietary JSON) toward the internal canonical model. It is the embodiment of the Pipes and Filters pattern applied to EDI.

Typical stages:

• Parser: opens the document, checks syntax, emits SyntacticallyValid or SyntacticallyInvalid.
• Validator: applies semantic rules (Schematron, JSON Schema, EN 16931), emits SemanticallyValid.
• Translator: converts to canonical model — Message Translator pattern.
• Enricher: resolves references (GLN, GTIN, partner master), Content Enricher pattern.
• Business validator: applies customer-specific business rules (credit limits, authorisation checks).

Each stage is a stateless service that consumes a topic and publishes to the next. Horizontal scaling follows the Competing Consumers pattern. Failures route to the Dead Letter Channel dedicated to each stage, with exponential-backoff-jitter retry.

Layer 3: canonical event store

At the hub's core, an immutable event store records all domain events: InvoiceReceived, InvoiceValidated, InvoiceTranslated, InvoiceRoutedToErp, InvoiceAckedByErp, InvoiceArchived, plus the corresponding error states. This logging follows the Event Sourcing pattern (Fowler 2005, Young 2010).

Several read models are derived from the log by projection:

• Operational dashboard: list of in-flight messages by state, partner, type.
• Partner-facing tracking portal: the partner follows its own messages from a dedicated console.
• Fiscal archive: immutable view consultable for 10 years with a link to the original signed payload.
• Analytics warehouse: continuous feed of a data warehouse for volumetric KPIs, cycle times, SLAs, churn.

Typical 2026 event store: Kafka for the append-only log, EventStoreDB or a PostgreSQL fork adapted for read-model snapshots. The CQRS pattern strictly separates writes (commands) and reads (projections).

Layer 4: partner state machines

Each EDI partner has its technical lifecycle, generally modellable as an explicit state machine: prospection → spec-exchange → cert-exchange → connectivity-test → production-pilot → production-active → archived. This state machine, persisted and observable, is the backbone of partner management in a multi-tenant hub.

The State Machine pattern applied to partners complements the one applied to messages. Transitions are triggered either manually (operator validation) or automatically (connectivity test success, certificate expiry). Candidate workflow engines: Camunda 8, Temporal, AWS Step Functions, Spring State Machine.

Layer 5: multi-tenant observability

A modern EDI hub instruments all flows with OpenTelemetry (traces, metrics, logs) correlated by a stable traceId. Each message carries its traceId from ingest onward, and each service injects its spans into the shared trace. The Correlation Identifier pattern is fundamental.

Multi-tenant slicing demands:

• Systematic tagging: each metric, each log carries tenant_id, partner_id, document_type.
• Dashboard isolation: each tenant sees only its own flows.
• Per-tenant SLO: latency, error rate, delivered-ack rate. The Bulkhead pattern isolates resources so that a failing tenant does not affect others.
• Differentiated alerting: incident priority depends on the impacted tenant and its contract.

Why polyglot?

A modern EDI hub is rarely written in a single technical stack. Reasons:

• Mature parsing libraries: Java dominates EDIFACT parsers (Smooks, Mendelson, BOTS), Python excels at enrichment scripting, Go for high-performance ingest services, Rust for cryptographic components.
• Available skills: forcing Java on a new component while the team masters Go slows down delivery.
• Per-service encapsulation: each service exposes a stable API (gRPC, REST), the implementation stays free. Newman, Building Microservices, 2nd ed. 2021, codifies this principle.

The trade-off: strict standardisation of contracts (Protobuf schemas, OpenAPI specs, AsyncAPI specs), unified yet polyglot CI/CD, and a common platform (Kubernetes, observability stack, secret management).

Security: Zero Trust by default

The Zero Trust Architecture pattern (NIST SP 800-207) applies to modern EDI: every inter-service call is mTLS-authenticated and authorised, secrets are rotated via Vault/KMS, partner certificates are managed in pipeline, sensitive flows are encrypted at rest via KMS (Secrets Management pattern).

The Defense in Depth pattern stacks: edge WAF, mTLS service mesh, granular IAM, immutable audit logs, environment separation (isolated prod, pre-prod, dev).

Conclusion: a mature architectural pattern

The ISGo 2026 architecture is hardly revolutionary: it consolidates known patterns (Hohpe-Woolf 2003, Fowler 2014, Newman 2015, Kleppmann 2017, Burns 2017) and applies them rigorously to a domain — EDI — where audit, tax compliance and robustness weigh as much as performance. For a vendor or an EDI department it is the reference standard for 2026-2030. Forthcoming evolutions (post-quantum, AI-assisted mapping, unified eBPF observability) will add on, but the layers are laid.

See also the articles on EDI patterns, EDI in the API era and the modern architecture foundation.