Event Message

The notification message — real-time pub/sub, modern Kafka pattern.

Problem

How to notify several interested systems of a state change (ORDERS confirmed, INVOIC paid, container arrived) without coupling sender to recipients?

Forces

• Sender must not know recipients (decoupling).
• Recipients can process at their own pace (variable latency).
• Events must be archivable for replay and debugging.
• An event does not change — it is a past fact.

Solution

Publish the event on a Publish-Subscribe channel. The sender does not know who listens. Subscribers register and react. Naming convention: past-tense verb (OrderConfirmed, InvoicePaid, ContainerArrived). Immutable payload, sourcing from Event Log for replay.

EDI implementation

In modern event-driven EDI, Event Messages represent state changes in flows: OrderReceived, InvoiceValidated, MdnAcknowledged, EdifactParsed. Architecture: Kafka topic edi.events, each business service (analytics, compliance, dashboard) subscribes per its need. Full Event Sourcing possible — reconstruct an INVOIC state from its events.

Anti-patterns

• Event named in future tense or imperative (CreateOrder) — that is a Command, not an Event.
• Sender waiting for a reply — that is request/reply, not Event.
• Event retroactively modified — a past fact is immutable.

Related patterns

• Command Message — complementary pattern.
• Document Message — third style.
• Publish-Subscribe — typical event channel.

Sources

• Hohpe G., Woolf B. — EIP, Event Message (p. 151). www.enterpriseintegrationpatterns.com/patterns/messaging/EventMessage.html