Introduction: Event-Driven Architecture Is Not Magic, It's Trade-offs
Event-Driven Architecture (EDA) has been sold for years as the silver bullet for scalability, decoupling, and “future-proof” systems. The reality is harsher. EDA is not inherently simpler, safer, or cheaper than request/response architectures. It merely shifts complexity from synchronous coordination to asynchronous uncertainty. If you don't explicitly design for that shift, you don't get a resilient system—you get distributed chaos with better marketing. Many teams adopt events because “microservices need them,” without understanding the patterns that make events useful rather than destructive.
The modern EDA conversation often skips the uncomfortable parts: event granularity decisions, semantic stability, consumer-driven evolution, and the operational cost of running event infrastructure at scale. Worse, teams frequently conflate events, messages, commands, and logs, treating them as interchangeable. They are not. This confusion leads directly to anti-patterns like the infamous Swarm of Gnats, where systems drown in tiny, meaningless events that increase coupling instead of reducing it.
This article is a brutally honest guide to the EDA patterns that actually matter today. We'll focus on derived event granularity, when to emit coarse vs fine-grained events, how to avoid consumer explosion, and how real-world systems fail when these patterns are ignored. The goal is not theoretical purity—it's systems that survive contact with production.
What an Event Really Is (And Why Most Systems Get This Wrong)
An event is a statement of fact about something that already happened, expressed in a way that other parts of the system can rely on. This definition aligns with Martin Fowler's work on event-driven systems and Gregor Hohpe's Enterprise Integration Patterns. Events are not instructions, they are not questions, and they are not “things we might want someone to react to.” They are immutable records of state change, published after the fact, and owned by the producer's domain.
Many systems fail because they treat events like remote procedure calls in disguise. They emit events such as ValidateUser, CalculateDiscount, or SendEmail. These are commands, not events. Commands imply intent and expectation; events imply history. Once you cross that line, you've already reintroduced tight coupling—just asynchronously. Consumers now depend on producer intent, not producer truth, which makes evolution painful and coordination fragile.
A correct event communicates business meaning, not technical steps. OrderPlaced, PaymentCaptured, or ShipmentDispatched are stable facts that can be reasoned about years later. This distinction is not pedantic; it directly affects how granular your events should be, how many consumers you can support, and whether your system remains intelligible over time. If you can't explain an event to a non-engineer in the business domain, it's probably the wrong event.
Event Granularity: The Most Expensive Decision You'll Make
Event granularity is the decision of how much information and semantic weight each event carries. Too coarse, and consumers lose flexibility. Too fine, and you create a dependency nightmare. This is where most EDA implementations quietly fail, because teams treat granularity as a technical detail instead of a product decision.
Fine-grained events—like UserEmailUpdated, UserAddressUpdated, UserPhoneUpdated—seem attractive at first. They feel precise and reusable. In practice, they explode consumer complexity. Each downstream service must now reconstruct business meaning by correlating multiple events, often across time and partitions. This introduces temporal coupling and makes reasoning about system state significantly harder. Debugging becomes archaeology.
On the other end, overly coarse events—like UserProfileChanged with a giant payload—create different problems. Consumers now depend on internal producer structure, payload schemas grow uncontrollably, and backward compatibility becomes fragile. Every small internal change risks breaking multiple consumers. Neither extreme scales well.
Granularity is not about payload size; it's about semantic completeness. An event should represent a business-relevant transition that is meaningful on its own. If a consumer needs to listen to five events to understand what happened, your granularity is wrong. If a consumer needs to parse half your domain model to get value, it's also wrong.
Derived Event Granularity: Designing for Consumers Without Coupling
Derived event granularity is the practice of deriving additional events from internal state changes, rather than exposing every internal mutation directly. This pattern allows producers to keep fine-grained internal models while emitting coarser, consumer-aligned events at the boundary. It is widely used in mature event-driven systems, even if teams don't always name it explicitly.
Instead of publishing raw internal events like OrderItemAdded or OrderPriceRecalculated, a service might internally process those changes and emit a derived event such as OrderConfirmed. This derived event represents a meaningful milestone that downstream systems actually care about. Internals remain flexible, while the external contract stays stable. This aligns with ideas described by Martin Kleppmann in Designing Data-Intensive Applications, particularly around log-derived views and stream processing.
Derived events are often produced using stream processors (Kafka Streams, Flink, Kinesis Analytics) or even simple internal workflows. The key insight is that not every state change deserves to be public. Public events should be curated, opinionated, and boringly stable. If you treat your event stream like an internal debug log, consumers will suffer.
This pattern also enables multiple views of the same reality. Different derived events can be produced for different audiences without leaking internal complexity. That's not duplication—it's intentional abstraction. Systems that scale long-term do this relentlessly.
The Swarm of Gnats Anti-Pattern: Death by a Thousand Events
The Swarm of Gnats anti-pattern describes systems that emit massive volumes of tiny, low-value events that overwhelm consumers and infrastructure. Each event does almost nothing on its own, but together they create noise, cost, and coupling. Gregor Hohpe popularized this concept, and it remains painfully relevant.
You see this pattern when teams emit events for every CRUD operation: EntityCreated, EntityUpdated, FieldChanged, FlagToggled. These events are easy to generate and feel “complete,” but they push interpretation complexity downstream. Consumers now need deep domain knowledge just to react correctly. Worse, small producer changes ripple through dozens of consumers.
Operationally, Swarm of Gnats systems are expensive. High event volume increases broker costs, storage costs, and operational burden. Latency-sensitive consumers struggle to keep up, and replaying streams becomes impractical. Teams respond by adding filters, projections, and compensations—essentially rebuilding structure that should have existed at the producer boundary.
The brutal truth: if your event stream looks like a database changelog, you didn't design an event-driven system—you exported your ORM. Events should reduce cognitive load, not multiply it.
Practical Patterns That Actually Work in Production
The first pattern that consistently works is business milestone events. These are events emitted only when something meaningful has completed from a domain perspective. They are infrequent, stable, and easy to reason about. Examples include SubscriptionActivated, LoanApproved, or GameRoundSettled. They drastically reduce consumer complexity and survive schema evolution far better than low-level events.
Another effective pattern is event versioning via additive evolution, not breaking changes. This aligns with guidance from AWS EventBridge and Kafka schema registries. You add fields, never remove or repurpose them. Consumers opt into new semantics explicitly. This sounds obvious, yet many teams break consumers by “cleaning up” payloads without realizing events are contracts, not DTOs.
Finally, successful systems embrace asynchronous boundaries with synchronous islands. Not everything needs to be event-driven. Critical paths often remain synchronous for clarity and consistency, while events are used for propagation, integration, and side effects. Systems that force everything through events usually end up slower and harder to reason about than hybrid designs.
Code Example: Emitting Derived Events Instead of Internal Noise
Below is a simplified TypeScript example showing how internal state changes can produce a derived, consumer-facing event rather than multiple low-level ones.
// Internal domain logic
class Order {
private items: Item[] = [];
private status: 'DRAFT' | 'CONFIRMED' = 'DRAFT';
addItem(item: Item) {
this.items.push(item);
}
confirm() {
if (this.items.length === 0) {
throw new Error('Cannot confirm empty order');
}
this.status = 'CONFIRMED';
}
}
// Derived event emission
function handleOrderConfirmation(order: Order) {
order.confirm();
eventBus.publish({
type: 'OrderConfirmed',
occurredAt: new Date().toISOString(),
payload: {
orderId: order.id,
itemCount: order.items.length,
totalPrice: order.totalPrice
}
});
}
This approach hides internal churn and exposes a single, semantically rich event. Consumers don't care how many items were added or recalculated—they care that the order is now confirmed. That's the difference between signal and noise.
The 80/20 of Event-Driven Architecture
If you want 80% of the benefits of EDA with 20% of the pain, focus on these insights. First, design events as products, not side effects. Name them carefully, document them, and treat them as long-term contracts. Second, opt for fewer, richer events over many tiny ones. Volume is not a proxy for correctness. Third, derive events at the boundary, not directly from persistence or ORM hooks.
Most teams fail at EDA not because the technology is hard, but because they refuse to say no to bad events. Discipline beats tooling every time.
Analogies That Actually Stick
Think of events like newspaper headlines, not raw surveillance footage. A headline summarizes what matters; footage is exhaustive but useless without context. Swarm of Gnats systems publish footage. Good EDA publishes headlines.
Another useful analogy is urban planning. Internal state changes are like foot traffic inside buildings—necessary but private. Public events are roads and intersections. If you expose every hallway as a public road, the city becomes unusable. Abstraction is not hiding—it's survival.
Conclusion: Event-Driven Architecture Rewards Maturity, Not Enthusiasm
EDA is not a beginner-friendly architecture, and pretending otherwise does teams a disservice. It demands strong domain modeling, disciplined boundaries, and a willingness to say “no” to technically correct but strategically harmful events. Patterns like derived event granularity exist because real systems hurt without them.
If you remember one thing, remember this: events are a language. If you speak in noise, your system will listen in confusion. If you speak in meaning, it might actually scale.
Design fewer events. Make them boring. Let your consumers sleep at night.