Event-Driven Architecture — The Concept Behind Modern Integration
Most systems are request-driven. You ask them for something; they respond. Simple, predictable, easy to reason about. But this model has a limit: it requires the caller to know who to ask and when to ask them.
Event-driven architecture turns this around. Instead of asking, systems broadcast what happened. Other systems listen and react if it is relevant to them. The sender does not know or care who is listening.
This shift in thinking — from asking to broadcasting — is behind some of the most important architectural decisions in modern software. This post explains the concept, the patterns, the tools and where it actually makes sense to use it.
🔗 Related context
This post extends SAP Integration Patterns which introduced event-driven integration in the SAP context. That post covers the when-to-use decision. This post covers the concept in full — universally, not just in SAP.
Events, commands and queries — the three message types
Before getting into architecture, it is worth being precise about terminology. Three types of messages are often confused:
| Message type | What it is | Direction | Example |
|---|---|---|---|
| Event | A fact — something that happened, stated in past tense | Publisher to anyone interested | OrderPlaced, InvoicePosted, CustomerUpdated |
| Command | An instruction — telling another system to do something | Sender to a specific receiver | ProcessOrder, SendEmail, CreateRecord |
| Query | A request for information — expecting a response | Requester to a specific responder | GetCustomerById, ListOpenOrders |
Event-driven architecture specifically concerns events. An event says: this thing happened. It does not tell anyone what to do about it. That decision belongs to whoever is consuming the event.
💡 Why past tense matters
Naming events in past tense (OrderPlaced, not PlaceOrder) forces clarity. PlaceOrder is a command — it tells a system what to do. OrderPlaced is a fact — it records what already happened. The distinction matters: an event cannot be refused, retried or altered. It happened. Consumers decide what to do with that fact.
The publish-subscribe pattern
The pub/sub pattern is the foundation of event-driven architecture. There are three roles:
| Role | What it does | Key characteristic |
|---|---|---|
| Publisher | Produces and emits events when something happens in its domain | Does not know who is listening — publishes and moves on |
| Event Broker | Receives events from publishers and routes them to subscribers | Decouples publishers from consumers — neither needs to know about the other |
| Subscriber | Consumes events it has expressed interest in | Reacts on its own terms — can be slow, offline or added later without affecting the publisher |
Why event-driven — the core benefits
| Benefit | What it means in practice |
|---|---|
| Loose coupling | The publisher does not know its consumers — you can add, remove or replace consumers without touching the publisher |
| Independent scaling | Each consumer scales independently based on its own processing needs — not constrained by the publisher’s capacity |
| Resilience | If a consumer is down, the event broker holds the events. When it recovers, it processes them. No data is lost. |
| Extensibility | Adding a new consumer is a subscription — no change to the publisher or existing consumers |
| Temporal decoupling | Publisher and consumer do not need to be available at the same time — unlike synchronous calls |
Event brokers — the infrastructure layer
An event broker is the platform that receives, stores and delivers events. Choosing the right broker is an infrastructure decision.
| Broker | Who runs it | Best suited for |
|---|---|---|
| Apache Kafka | Self-hosted or managed (Confluent Cloud, AWS MSK) | High-throughput, high-volume event streaming — millions of events per second. Financial data, IoT, real-time analytics. |
| SAP Event Mesh | SAP — runs on BTP | SAP-to-SAP and SAP-to-third-party events. Standard SAP business event catalogue. Integrates natively with S/4HANA. |
| AWS EventBridge | Amazon Web Services | Cloud-native event routing between AWS services and SaaS applications |
| Azure Service Bus / Event Grid | Microsoft Azure | Enterprise messaging and event routing in Azure-centric architectures |
| RabbitMQ | Self-hosted or managed | Traditional message queuing — lower throughput than Kafka, simpler setup |
| Google Pub/Sub | Google Cloud | Scalable event streaming on GCP — similar positioning to Kafka for Google-native architectures |
💡 Kafka vs SAP Event Mesh
Kafka is a general-purpose high-throughput event streaming platform — it is the backbone of many non-SAP data pipelines. SAP Event Mesh is purpose-built for the SAP ecosystem — it carries SAP business events (SalesOrder.Created, BusinessPartner.Changed) and integrates directly with S/4HANA and BTP. They are not competitors; in a large SAP landscape you may use both.
💡 Kafka’s key concept: consumer groups
In a traditional message queue, each message is consumed once by one consumer. In Kafka, messages are stored in partitions and multiple consumers can read the same messages independently — each consumer group maintains its own position (offset) in the stream. This means your analytics system, your inventory system and your audit system can all consume the same OrderPlaced event independently, each at their own pace. If one consumer falls behind, the others are not affected. This is fundamentally different from RabbitMQ, where a message delivered to one consumer is gone for all others. Kafka retains messages for a configurable period — enabling replay of historical events, which traditional queues cannot do.
Domain events — designing good events
A domain event represents something meaningful that happened in a business domain. Good event design matters because events are public — once consumed, changing their structure breaks consumers.
- Use past tense, domain language — OrderShipped not ShipOrder, not order_status_changed
- Include enough context — the consumer should not need to call back to get more information
- Include a timestamp and a unique event ID — essential for ordering, deduplication and debugging
- Keep events immutable — an event records what happened, it cannot be corrected. Corrections are new events.
- Version your event schema — as business requirements evolve, event structures change. Version them from day one.
| What to include in an event | Why |
|---|---|
| Event type (e.g. OrderPlaced) | Identifies what happened — consumers use this to decide whether to process |
| Event ID (unique) | Enables deduplication — consumers can detect and ignore duplicates |
| Timestamp | Records when it happened — essential for ordering and audit trails |
| Aggregate ID (e.g. orderId) | Identifies the business object the event relates to |
| Event data (payload) | The facts — what changed. Include enough that consumers do not need to call back. |
| Event version | Indicates the schema version — allows consumers to handle multiple versions gracefully |
Event-driven vs request-driven — when to use each
| Use event-driven when… | Use request-driven when… |
|---|---|
| Multiple systems need to react to one change | You need an immediate response in the same transaction |
| The publisher should not depend on consumer availability | Both systems are always available and tightly coordinated |
| You need to add consumers in the future without changing the source | There is only one consumer and it is unlikely to change |
| Processing can be eventual — not immediate | The user is waiting for the result right now |
| High volume — polling would generate excessive load | Low volume — the overhead of a broker is not justified |
One honest caution: event-driven architecture adds operational complexity. You now have a broker to manage, a schema to version, error handling for failed consumers and monitoring for message lag. For a simple integration between two systems that are always available, synchronous REST is simpler and more appropriate. Reserve event-driven design for the scenarios it genuinely solves — multiple consumers, eventual consistency, high volume, resilience to downstream failures. Using it as the default for every integration is an over-engineering trap.
Event-driven in the SAP landscape
| SAP scenario | Event-driven implementation |
|---|---|
| S/4HANA posts a goods movement | GoodsMovement.Created event published to SAP Event Mesh — WMS, analytics and finance systems each consume and react independently |
| New customer created in S/4HANA | BusinessPartner.Created event published — CRM, MDM and portal systems subscribe and sync the new record |
| Invoice approved | InvoiceApproved event triggers downstream payment scheduling and supplier notification — no direct API call needed |
| BTP service to BTP service | Microservices on BTP’s Kyma runtime communicate via Event Mesh — loose coupling between independently deployed services |
| S/4HANA to Kafka | Large-volume SAP events (stock movements, order changes) forwarded from Event Mesh to Kafka for real-time analytics pipelines |
At a glance — key concepts
| Concept | One-line summary |
|---|---|
| Event | A fact in past tense — something that happened in a domain |
| Command | An instruction to another system — direct, not event-driven |
| Pub/Sub | Publisher emits to a broker; subscribers consume independently — no direct coupling |
| Event Broker | The infrastructure that receives, stores and routes events between systems |
| Loose coupling | Publisher does not know its consumers — they can change without affecting the publisher |
| Temporal decoupling | Publisher and consumer do not need to be available simultaneously |
| Apache Kafka | High-throughput event streaming platform — millions of events per second |
| SAP Event Mesh | SAP’s event broker on BTP — carries standard SAP business events from S/4HANA |
| Domain event | A business-meaningful event — named in past tense, versioned, immutable |
What to take away
Event-driven architecture is not a replacement for request-driven design. It is an alternative for specific scenarios — particularly where multiple consumers need to react to the same change, where loose coupling matters, and where volume or resilience requirements make synchronous calls impractical.
In the SAP world, SAP’s standard event catalogue and Event Mesh make event-driven patterns more accessible than they have ever been. Understanding the concept — events as facts, pub/sub, decoupling — is what allows you to use those tools with architectural intention rather than just following a recipe.
🔗 Related posts on this site
SAP Integration Patterns — where event-driven sits relative to other SAP integration patterns. SAP BTP — The Platform Explained — SAP Event Mesh is one of the core BTP integration services. REST API Design Principles — request-driven APIs are the complementary pattern — understanding both makes the trade-offs clear. Docker and Containers — The Why — microservices running in containers are a common source and consumer of events in modern cloud architecture.
Published on rakeshnarayan.com — Articles
URL: https://rakeshnarayan.com/articles/event-driven-architecture/
