Event-Driven Architecture
Event-driven architecture (EDA) is an architectural style in which systems communicate through events: as soon as something relevant happens – such as a new order – one system produces an event that other, decoupled systems can read in real time and react to. Instead of calling each other directly, the building blocks exchange messages through a mediator.
Event-driven architecture (EDA) is a pattern for building distributed software: the systems or services involved do not communicate by calling each other directly, but by exchanging "events". An event is the observation that something significant has happened – an order was placed, a payment came in, a stock level changed. The system where this occurs publishes the fact as a message; other systems interested in it receive that message and react on their own. Sender and receiver do not know each other directly – they are decoupled through a mediator.
The heart of EDA is this decoupling in space and time: the producer of an event does not need to know who processes it, whether anyone processes it at all, or when that happens. This lets systems be developed, scaled and operated resiliently, independently of one another. In the ERP and e-commerce space, EDA is the foundation that allows shop, marketplace, inventory management, accounting and shipping to work together in near real time without being fused into one rigid block.
At a glance
- EDA = architectural style in which systems communicate through events rather than direct calls
- Core roles: producer (creates events), broker/event bus (mediates), consumer (reacts)
- Strong decoupling: the sender does not know the receiver – systems scale and evolve independently
- Enables real-time reactions and high resilience, but increases operational complexity
- In the ERP space, the basis for responsive integration of shop, payment, warehouse and accounting
How event-driven architecture works
An event-driven architecture involves three basic roles. The producer detects that an event has occurred and publishes it. The consumer is interested in certain events, receives them and triggers a reaction. In between sits a mediator – depending on the implementation an event broker, a message queue or an event bus – that accepts the events, buffers them and distributes them to all interested receivers. The producer therefore does not send its event to a specific addressee, but "into the room"; the broker decides who picks it up based on subscriptions.
An event itself is a compact, immutable record – usually in JSON format – that describes what happened: an event type (e.g. "OrderPlaced"), a timestamp and the relevant payload such as order number and line items. The difference between an event and a command is crucial: an event neutrally reports a fact that has already occurred in the past, without prescribing what should be done. A command, by contrast, requests a specific action. This inversion – "something happened" instead of "do this" – makes it possible to add new receivers at any time without changing the producer.
Publish-subscribe and event streaming
Two variants dominate in practice. In the publish-subscribe pattern (pub/sub), a producer publishes events to a "topic" (a subject channel); all consumers that have subscribed to that topic receive a copy. This way, a single order event can reach accounting, the warehouse and an analytics dashboard in parallel. In event streaming – for example with platforms like Apache Kafka – events are additionally stored as a durable, ordered history (a "log"). Consumers can read the stream from any point, catch up on missed events and replay the history. This is the basis for concepts such as event sourcing, in which the current state of a system is reconstructed from the complete history of all events.
Why event-driven architecture matters
The most important benefit of EDA is loose coupling. Because a producer does not know, and does not need to know, who processes its events, individual services can be replaced, updated or added without touching the others. When a new sales channel is added, it simply subscribes to the existing order events – nothing changes in the producing system. This independence reduces the risk that a change in one place unintentionally breaks something elsewhere.
Second, EDA enables real-time reactions: instead of polling at fixed intervals to check whether something has changed, systems react the moment the event occurs. Third, decoupling through a broker improves resilience and load distribution – if a consumer briefly goes down, its events remain in the queue and are processed later instead of being lost. And fourth, the model scales well: during load peaks, several consumers can process the same event stream in parallel. These properties make EDA the preferred communication pattern for microservices and composable system landscapes assembled from building blocks.
Event-driven architecture in the ERP system
An ERP is a company's central data hub – and that is exactly why EDA is so valuable here. In an event-driven landscape, the online shop reports the event "order received", whereupon the ERP creates the order, reserves stock and itself publishes a follow-up event "order created". The payment service provider reports "payment confirmed", the warehouse responds with picking, the shipping service acknowledges "parcel shipped", and accounting posts the transaction in parallel. Each step is an event that several systems react to independently – a chain that runs without central control.
In practice, individual events are often delivered via webhooks, while middleware or iPaaS platforms act as event brokers and translators. They accept events, transform them into the appropriate data format and distribute them to the target systems. The result is a responsive data flow that keeps stock synchronisation current across all channels and avoids overselling. EDA is therefore a central building block of modern integration – especially in composable and best-of-breed approaches, where many specialised systems have to work together.
The challenge of idempotency and ordering
Event-driven systems come with typical pitfalls. A broker often only guarantees that an event is delivered "at least once" – so it can arrive twice. Consumers must therefore work idempotently, so that a "payment confirmed" received twice does not lead to a double posting. Ordering is likewise not always guaranteed: if "order cancelled" arrives before "order created", the receiver must resolve this cleanly using timestamps or status fields. These requirements are manageable, but they belong in every integration project from the very start.
Distinction: EDA vs. request-response and ESB
The opposite of EDA is classic request-response communication, in which one system calls another directly via an API and waits synchronously for the response. This pattern is simple and easy to follow, but couples the systems tightly: the caller must know the callee and wait for it to be reachable and to respond. EDA, by contrast, works asynchronously and decoupled – no one waits, and the producer keeps running even if a consumer is currently unavailable. In real-world landscapes the two patterns complement each other: request-response for immediate queries, EDA for distributing events.
EDA differs from the enterprise service bus (ESB) mainly in its orientation. An ESB, a concept from classic SOA, provides a central, often intelligent integration layer that handles routing, transformation and orchestration. EDA, by contrast, shifts the logic to the edges: the broker mediates events as "dumbly" as possible, and the consumers themselves decide how to react. This makes the overall system more flexible and easier to extend, but distributes the complexity across many services – which makes observability, monitoring and well-thought-out error handling all the more important.
Example
Example: One order event triggers an entire chain
A mid-sized retailer of household goods sells through its own shop and two marketplaces. When a customer orders a food processor, the shop publishes the event "OrderPlaced" with order number, item and quantity to the event broker of the connected integration platform. The broker distributes it to all interested systems.
The ERP receives the event, creates the order, reserves stock and in turn publishes "StockChanged" – whereupon the two marketplaces adjust their availability and overselling is ruled out. In parallel, the shipping service waits for the "PaymentConfirmed" event from the payment service provider to trigger picking, and an analytics dashboard counts the order in real time. None of these systems knows the others directly; each reacts only to the events it has subscribed to. If the dashboard briefly goes down, it later catches up on the missed events from the stream – order processing continues unaffected.
Frequently asked questions
Matching ERP systems
Related services
Questions about Event-Driven Architecture in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.