Event-driven architecture

Event-driven architecture is a design style in which services talk by publishing a state-change event and letting other services react, instead of calling each other directly and waiting for an answer. It is a style you adopt, not a product you buy.

That last clause is the boundary worth holding. An enterprise integration platform is software you procure and licence; this is an approach your engineers choose, and it can be built on bought tooling or on open components.

A state-change event is simply a record that something happened: an order was paid, a shift was filled, a limit was breached. The event says what changed, and nothing about who should care.

The payoff is independence — a producer never needs to know who is listening, so a new consumer can be added without touching the service that emits the change.

Key takeaways

• Producers publish state changes; a router distributes them; consumers decide what to do next.
• Nobody waits in line, so one slow consumer no longer blocks the service that published.
• Replayable event logs make recovery and late-joining consumers far easier to support.
• The cost is traceability: debugging means following messages, not reading one call stack.

How it works

Event-driven architecture works through three parts. Amazon Web Services describes them as event producers, event routers and event consumers, where producers publish a change, the router filters and pushes it, and consumers act independently.

Two delivery models dominate, and they behave differently under failure. Microsoft’s architecture guidance notes that in event streaming, events are written to a durable log, so a client can join at any time and replay events.

The operational difference matters more than the diagram. A publish and subscribe consumer that was offline misses what it missed, while a streaming consumer rewinds and catches up on its own schedule.

Ordering and duplication are the two traps. Messages can arrive twice or out of sequence, so consumers have to handle a repeat without charging anyone twice, which is work a direct call never demanded.

Schemas stop the whole thing drifting. Publish the shape of each event and version it, because a quiet change to one field breaks every consumer at once and none of them owns the fix.

Contrast it with the scheduled world. Job scheduling software fires work at a fixed time whether or not anything has changed, which is predictable, cheap to reason about and always slightly behind reality.

Automation sits naturally on top. Hyperautomation programmes favour this style because each new bot or model subscribes to an existing stream rather than asking the source system for yet another interface.

The harder work is governance — deciding who may publish, what an event is allowed to contain, and how long the log is kept. An automation center of excellence is usually where those rules end up living.

Examples

The style shows up wherever a single change has several independent consequences and nobody wants the originating system to know about all of them. Retail, logistics, finance and service operations all qualify.

Online retail is the textbook case. An item added to a cart is a state change; pricing, stock, recommendation and fraud services each react to it without the storefront holding a list of who to call.

Logistics runs on status changes. A scan at a depot publishes once, and tracking pages, customer messaging and exception queues all update from that single message.

The alternative is every one of those systems polling a central database each minute, which costs more and still leaves the customer looking at a stale tracking page.

Service operations increasingly pair it with models. A cognitive automation service can subscribe to incoming case events, classify each one, and publish its verdict as a new event for routing rules to use.

Finance operations uses it for limits and alerts. A balance crossing a threshold publishes once, and treasury dashboards, approval rules and the audit log all react without anyone running a nightly report.

Team shape follows the style as well. Each consumer can be owned, deployed and scaled by a different team, which is much of why the pattern spread alongside microservices rather than before them.

The newest variant is agent-led. Agentic process automation tools behave as consumers that decide their own next action, which only works safely when every action they take is itself published and auditable.

Related terms

• Data-directed call routing: routing contacts using live data; an early, narrow use of reacting to changes.
• Digital payment: payment flows that publish authorisation and settlement changes other systems consume.
• Hyperautomation: automating broadly across tools; event streams are how its parts stay in step.
• Job scheduling software: runs work on a clock rather than on a change, and remains the right answer for batch.
• Cognitive automation: model-based judgement in a workflow, often consuming and emitting events.

FAQ

What is an event in this context?

A record that something changed in a system, such as a payment clearing or a ticket closing. It carries the change itself, or a pointer to it, and no instruction about who should respond. Keeping instructions out is what lets consumers change independently.

How is this different from an integration platform?

An integration platform is a product you buy; this is an architectural style you adopt. The style can run on purchased tooling, on open components, or on a mix of both.

When is it the wrong choice?

When the work is genuinely sequential, low in volume and easier to trace as a direct call — debugging distributed messages costs real engineering time that a small system will never earn back.

Does it reduce running costs?

It can — push-based delivery removes the constant polling that burns capacity while waiting for something to happen. Broker licences and the operations effort behind them partly offset that saving, so model both sides.

Can an outsourced team support this architecture?

Yes, provided runbooks cover replay, poison messages and dead-letter handling, which are the failure modes newcomers meet first. Hand over the event catalogue along with the access.

Explore outsourcing models and provider options across the Outsource Accelerator site before you scale the team that runs it.