At some point in the growth of almost every enterprise system, a specific kind of pain sets in. A change to one service breaks another. A new integration requires three teams to coordinate a deployment window. A downstream system needs to be updated every time upstream data changes, and doing so requires the upstream system to know — and care — about every consumer that depends on it. The system still works. It just gets harder to change, harder to scale, and harder to reason about with every addition.
This is the tightly coupled monolith problem, and it doesn’t only affect organizations that built everything in a single codebase. It affects any architecture where services communicate through direct, synchronous calls and share implicit knowledge about each other’s behavior. The coupling may be distributed across microservices, but the brittleness is the same.
Event-driven architecture (EDA) is the most widely adopted pattern for addressing this problem at enterprise scale, and the shift toward it is already well underway. In a global 2022 survey of IT and engineering leaders, 97% reported their organizations were already tapping into real-time data streaming in some form1. The idea itself is straightforward: instead of services calling each other directly, they communicate by publishing and subscribing to events. A service announces that something happened; other services that care about that event react to it. The publisher doesn’t know who’s listening. The subscribers don’t need the publisher to be available when they process the event.
This article explains how EDA works, where it delivers genuine value, the trade-offs that most introductions gloss over, and how to assess whether your architecture is a good candidate for the pattern.
What Event-Driven Architecture Actually Means
The control for this is a message broker or event streaming platform that sits between producers and consumers. Apache Kafka, AWS EventBridge, Azure Service Bus, and Google Pub/Sub all serve this role, with Kafka the most widely deployed of the group: Apache Kafka’s own project site states that more than 80% of Fortune 100 companies use it2. The broker decouples producers from consumers in both space (they don’t need to know about each other) and time (they don’t need to be running simultaneously).
What this unlocks, at its simplest, is the ability to add a new consumer of an event without modifying the producer. Your inventory service publishes an “order placed” event. Today, your fulfillment service and your analytics pipeline consume it. Tomorrow, you add a fraud detection service that also needs to react to new orders. The inventory service code doesn’t change. Neither does the fulfillment service. You add a new subscriber and you’re done.Four EDA Patterns and When to Use Each
Pattern
Best for
Watch out for
“Event notification” is the simplest form: a service publishes a small event indicating that something happened, typically containing just an identifier and a timestamp. Consumers that need to act on the event fetch the relevant state themselves from the originating service. This keeps event payloads light but requires consumers to make an additional call to get the data they need.
“Event-carried state transfer” includes the full state of the changed entity in the event payload. Consumers receive everything they need to process the event without making a subsequent call. This reduces inter-service communication but increases payload size and requires producers to decide upfront what data consumers will need: a decision that can be hard to get right.
“Event sourcing” goes further: rather than storing current state in a database, the system stores the complete sequence of events that produced that state. Current state is derived by replaying events. This gives you a complete audit trail and the ability to reconstruct state at any point in time, which is valuable in financial, compliance, and regulatory contexts. The trade-off is significant added complexity: querying current state requires materializing projections, and the operational overhead of managing event streams as the source of truth is substantial.
“CQRS (Command Query Responsibility Segregation)” separates the write model (where commands are processed and events are produced) from the read model (purpose-built projections optimized for specific query patterns). It is often used in conjunction with event sourcing but can be applied independently. CQRS shines in read-heavy systems where query complexity has become a performance bottleneck on the write-side database. Its cost is the need to manage consistency between write and read models, which are eventually — not immediately — consistent.
The costly version of this mistake isn’t picking the wrong EDA pattern; it’s not picking deliberately at all. Teams under integration pressure often reach for whatever pattern was covered in the last vendor talk, usually event sourcing or CQRS, before confirming the simpler options don’t already solve the problem. That instinct is understandable. In the same 2022 survey, 60% of IT leaders named difficulties integrating multiple data sources as the single biggest hurdle to their real-time data initiatives3 and the more complex patterns can feel like they address that pain fastest. In practice, they usually just relocate it.
Most enterprises benefit from starting with event notification or event-carried state transfer. Event sourcing and CQRS are powerful tools, but they are also significantly more complex to operate correctly. Reach for them when the specific capability they provide — full replay, audit history, or optimized read models — is genuinely required, not as a default.
The Real Trade-Offs EDA Introduces
EDA solves real problems. It also introduces new ones, and the organizations that have the hardest time with it are typically those that adopted it for the coupling and scalability benefits without fully internalizing the operational trade-offs.
Eventual consistency. In a synchronous, request-response system, a caller receives a response when the operation is complete and all state changes have taken effect. In an event-driven system, the producer publishes an event and moves on. Downstream consumers will process that event, but not necessarily immediately. For many use cases, this is acceptable. For others — reading your own writes, financial transactions, anything where stale state has material consequences — it requires careful design or the introduction of compensating patterns.
Distributed debugging. When a request crosses a synchronous call chain, tracing it is relatively straightforward: each call is in the stack. When a workflow spans multiple asynchronous event handlers, correlating what happened across producers and consumers requires distributed tracing infrastructure and consistent correlation IDs on every event. Without this investment, diagnosing a production issue in an event-driven system can be significantly harder than in a synchronous one.
Schema evolution. Events are contracts between producers and consumers. When you change the structure of an event — adding a field, removing one, changing a type — you need to ensure that existing consumers can still process the event correctly. In a synchronous API, this is managed through versioning at the endpoint level. In an event-driven system, it requires explicit schema management, typically through a schema registry, and a versioning strategy (backward compatibility, forward compatibility, or full compatibility) that all teams understand and follow.
The waste pattern here is treating these trade-offs as someday problems: shipping the first event-driven flow, deferring tracing and schema governance until “we have more consumers,” and then discovering that retrofitting both under production load costs far more than building them in from the start.
None of these trade-offs are reasons to avoid EDA. They are reasons to go in with a clear operational plan: distributed tracing from day one, a schema registry before you have more than two consumers of any event stream, and explicit consistency requirements documented for each domain.
The gap between intention and practice here is well documented. In the same 2022 survey, 76% of IT leaders said timely integration of real-time data from different applications was important to their organization, yet 40% admitted they still struggled to integrate it in a timely way4, a gap that’s usually explained less by the underlying technology than by the operational groundwork this section describes.
EDA vs. Direct API Calls: How to Decide
The question most architects face isn’t “should we adopt EDA” but “where should we use EDA versus direct API calls.” The answer depends on three factors: coupling tolerance, consistency requirements, and fan-out pattern.
Direct API calls are the right choice when the caller needs an immediate response to proceed, when the operation involves a two-way exchange of state, or when the number of consumers is small and stable. A user authentication flow is a synchronous operation by nature: the caller needs to know immediately whether the credentials are valid. An inventory reservation during checkout requires a synchronous confirmation that the item is available before the order can proceed.
EDA is the right choice when a single action needs to trigger multiple downstream reactions, when producers and consumers should be able to evolve independently, when consumers need to process at their own pace, or when you need a durable record of what happened. Order fulfillment, audit logging, analytics pipelines, notifications, and cache invalidation are all natural fits.
The practical heuristic: if the producer needs to know the result of what consumers do with the event, use a synchronous call. If the producer doesn’t — and shouldn’t — care about the consumers, use an event. The coupling concern is the reliable signal. Everything else is secondary.
The waste pattern in this decision is treating it as a one-time architectural stance rather than a per-integration judgment call. An organization that goes “all-in” on synchronous APIs recreates the coupling problem this article opened with. One that goes “all-in” on events adds asynchronous complexity to interactions that never needed it, like login or payment authorization. The heuristic above is meant to be applied integration by integration, not adopted as a company-wide default in either direction.
Getting that judgment right has a measurable payoff. In the same 2022 survey, organizations with widespread access to real-time data reported higher revenues overall, and 63% of that group saw annual revenue growth of 10% or more between 2020 and year-end 20215.
A Real Migration: How Salesforce Replaced Point-to-Point Integrations with Platform Events
Salesforce’s own engineering team has published a real, named example of this exact failure mode. Before building Platform Events, data integration with Salesforce was handled mostly by moving datasets in or out through the REST and SOAP APIs, and business-process integration ran through direct web-service calls made from Apex, Salesforce’s proprietary programming language.
Because the platform had no native publish-subscribe mechanism, customers who needed one built their own. In the words of Salesforce’s engineering team, “in the absence of native support, they had to emulate queueing with custom objects.” The cost of that workaround was concrete: “this caused a lot of extra work and considerable runtime overhead, so customers had to maintain fragile and slow systems, and pay extra storage fees”6.
Salesforce’s answer, described on its own engineering blog, was Platform Events: an event architecture modeled directly on Kafka’s append-only log. Publishers write once, each event gets an ordered offset, and any number of subscribers can discover new event types and track their own read position independently, without the broker having to hold subscriber-specific state. The design goal, in the team’s own words, was to let subscribers “discover the new message types and start listening to them completely independently from the publisher”7, the same decoupling principle described earlier in this article, applied inside one of the platforms enterprises already build on.
Event-driven architecture is not a silver bullet, and it is not the right pattern for every integration. But for enterprises managing systems that need to scale, evolve independently, and support an expanding ecosystem of consumers, it is one of the most reliable architectural investments available. The organizations that get the most out of it are those that adopt it deliberately: starting where the coupling pain is real, building the observability infrastructure in parallel, and resisting the temptation to apply the most complex patterns before the simpler ones have proven their value.
The pattern is established. The tooling is mature. The remaining variable is the discipline to use it where it fits, and to leave it alone where it doesn’t.
Notes
Sources Consulted
Apache Software Foundation — Apache Kafka (official project site) — https://kafka.apache.org/ (cited)
CloudKitchens Tech Blog — “Reliable Order Processing” — https://techblog.cloudkitchens.com/p/reliable-order-processing
Confluent — “How Walmart Uses Apache Kafka for Real-Time Omnichannel Replenishment” — https://www.confluent.io/blog/how-walmart-uses-kafka-for-real-time-omnichannel-replenishment/
Confluent — “Moving from Kafka Management to Retail Innovation at BigCommerce” (customer story) — https://www.confluent.io/customers/bigcommerce/
Confluent — press release, “Organizations with Real-Time Data Streams See Higher Revenues and Happier Customers, Confluent Report Finds” (2022 State of Data in Motion report) — https://www.confluent.io/press-release/confluent-data-in-motion-report-2022/ (cited)
Confluent — “The State of Data in Motion”, full report PDF (2022) — https://assets.confluent.io/m/5768834884a1504a/original/20220512-RPT-Data_in_Motion-ENG.pdf
Confluent — “Walmart’s Real-Time Inventory Management Powered by Kafka” — https://www.confluent.io/blog/walmart-real-time-inventory-management-using-kafka/
DORA — Accelerate State of DevOps Report 2023 — https://dora.dev/research/2023/dora-report/
DORA — “Capabilities: Loosely Coupled Teams” — https://dora.dev/capabilities/loosely-coupled-teams/
DZone — “Scaling E-commerce With Kafka Event-Driven Microservices” — https://dzone.com/articles/kafka-event-driven-ecommerce-migration
eWEEK — “Apache Kafka Gains Adoption as Streaming Data Grows” — https://www.eweek.com/big-data-and-analytics/apache-kafka/
Factor House — “How Walmart Uses Apache Kafka in Production” — https://factorhouse.io/articles/walmart-kafka-architecture
GitHub — vaquarkhan/flowing-retail-microservice-kafka (reference implementation, not a real company case study) — https://github.com/vaquarkhan/flowing-retail-microservice-kafka
Kai Waehner — “Use Cases for Apache Kafka in Retail” — https://www.kai-waehner.de/blog/2021/01/28/apache-kafka-in-retail-use-cases-architecture-case-studies-examples/
Salesforce Engineering (Medium) — “How Apache Kafka Inspired Our Platform Events Architecture” — https://engineering.salesforce.com/how-apache-kafka-inspired-our-platform-events-architecture-2f351fe4cf63/ (cited)
Walmart Global Tech (Medium) — “Introduction to Event-Driven Architecture” — https://medium.com/walmartglobaltech/introduction-to-event-driven-architecture-84cec03047f
