Most enterprise systems are built on request-response. A user clicks a button, the system processes the request, returns a response. Simple. Predictable. And increasingly inadequate for the complex, multi-system workflows that modern enterprise operations require. Event-driven architecture offers a fundamentally different model - and for certain types of enterprise work, it's not just better. It's the only approach that scales without turning your codebase into a tangled web of synchronous dependencies.
What You Need to Know
- Event-driven architecture decouples systems by communicating through events rather than direct calls
- It's particularly suited to enterprise workflows that span multiple systems and don't need immediate responses
- The trade-off is complexity: event-driven systems are harder to debug, test, and reason about
- Start with request-response as the default. Move to events when the coupling or scaling pain becomes real.
The Problem with Request-Response at Scale
Request-response works beautifully when System A talks to System B. A calls B, waits for the answer, continues. Clean. Simple. Debuggable.
The trouble starts when System A talks to System B, which talks to System C, which talks to System D. Each call is synchronous. Each system waits for the next one. If System D is slow, everything is slow. If System D is down, everything is down. The chain of dependencies creates a fragility that compounds with every new system added.
73%
of enterprise organisations operate more than 100 interconnected applications
Source: MuleSoft Connectivity Benchmark Report, 2020
In enterprise environments with dozens or hundreds of interconnected applications, request-response chains become unmanageable. A single slow service degrades everything downstream. A change in one system's API breaks everything upstream. The coupling is invisible until something fails, and then it's everywhere.
What Event-Driven Means
In event-driven architecture, systems communicate by publishing events rather than calling each other directly.
When a customer places an order, the order service publishes an "OrderPlaced" event. The inventory service subscribes to that event and reserves stock. The billing service subscribes and creates an invoice. The notification service subscribes and sends a confirmation email. Each service does its work independently. None of them know about or depend on the others.
The key difference: the order service doesn't call the inventory service. It announces what happened. Any interested service can respond. This decoupling is the fundamental advantage.
Three Patterns
Event notification. The simplest form. Something happened. Other systems may care. The event carries minimal data - usually just an ID and an event type. Interested consumers fetch the details they need. Low coupling, but requires the consumers to make follow-up calls.
Event-carried state transfer. The event carries the full data needed for consumers to act without calling back. More data on the wire, but consumers are fully independent. We use this for cross-system data synchronisation.
Event sourcing. Every state change is stored as an event. The current state is derived by replaying events. Powerful for audit trails and temporal queries. Complex to implement. We reserve this for systems where the audit trail is a core requirement, not a nice-to-have.
Where It Fits in Enterprise
Order Processing
A customer order touches inventory, billing, shipping, notifications, and reporting. In a synchronous system, the order endpoint calls five services in sequence. If any one fails, the entire order fails. With events, the order is recorded, and each downstream service processes it independently. A temporary billing outage delays the invoice without blocking the shipment.
Data Synchronisation
Enterprise systems need to share data: customer records, product catalogues, employee directories. Synchronous APIs create tight coupling and versioning nightmares. Events allow each system to maintain its own view of shared data, updated asynchronously.
Every enterprise I've worked with has a data synchronisation problem they're solving with scheduled batch jobs and duct tape. The investment in event infrastructure pays for itself within a year.
John Li
Chief Technology Officer
Audit and Compliance
Regulated industries need audit trails. Event-driven systems produce them naturally. Every event is a record of something that happened, when it happened, and who triggered it. The audit trail isn't a bolt-on feature. It's a by-product of the architecture.
The Trade-Offs
Debugging Is Harder
When a request-response chain fails, you can follow the stack trace. When an event-driven workflow fails, you need to trace events across multiple services, message brokers, and processing queues. Correlation IDs help. Distributed tracing tools help. But the debugging experience is fundamentally more complex.
Eventual Consistency
Event-driven systems are eventually consistent, not immediately consistent. After an order is placed, the inventory might take a few seconds to update. For most enterprise workflows, this is acceptable. For some - financial transactions, real-time trading - it's not. Know which world you're in before choosing the architecture.
Testing Complexity
Unit testing an event producer or consumer is straightforward. Integration testing the full event-driven workflow is hard. You need to verify that events are published correctly, consumed correctly, and that the eventual state is correct. We invest heavily in contract testing between services: each service's tests verify that it produces and consumes events in the agreed format.
Our Stack
For most enterprise clients, we recommend:
- Message broker: Apache Kafka for high-throughput, RabbitMQ for simpler workflows
- Event schema: JSON Schema or Avro with a schema registry
- Monitoring: Distributed tracing with correlation IDs across all events
- Dead letter queues: For events that fail processing, with alerting and retry mechanisms
The tooling has matured significantly in the past two years. Setting up a reliable event-driven pipeline is no longer a multi-month infrastructure project. It's a few weeks of setup with well-supported, well-documented tools.
When to Stay with Request-Response
Not everything needs events. Simple CRUD applications, internal tools with a single database, systems with low integration complexity - request-response is simpler, faster to build, and easier to maintain. Don't introduce event-driven architecture because it's architecturally interesting. Introduce it because the coupling or scaling pain is real and measurable.
Start with the simplest thing that works. Evolve when the pain tells you to.