Synchronous request/response is the default mental model most developers reach for, but it quietly couples services in a way that becomes painful at scale — if service A calls service B directly, A now depends on B being up, fast, and correct, for every single request. Event-driven architecture breaks that coupling by having services communicate through events instead.
Event-driven architecture is a pattern where services communicate by publishing and subscribing to events, rather than calling each other's APIs directly. A service that completes an action (an order is placed) publishes an event describing what happened, and other services that care (inventory, notifications, analytics) subscribe and react independently, without the originating service knowing or caring who's listening.
Why Event-Driven Architecture Matters (and When to Skip It)
Decoupling through events means the order service doesn't need to know about inventory, notifications, or analytics at all — it just publishes "order placed" and moves on. New subscribers can be added later without modifying the publisher, and a slow or failing subscriber doesn't block the publisher's own response, which is a meaningfully different failure mode than a synchronous call chain where any downstream failure propagates back to the caller.
Skip event-driven architecture for simple applications with few services and no genuine need for this decoupling — the added infrastructure (a message broker, event schema management, eventual consistency reasoning) is real complexity that isn't justified for a small system where direct API calls are simpler to understand, trace, and debug.
Getting Started with Event-Driven Architecture
Publishing an event after a state change:
async function placeOrder(orderData: OrderInput) {
const order = await db.orders.create(orderData);
await eventBus.publish("order.placed", {
orderId: order.id,
userId: order.userId,
items: order.items,
timestamp: new Date().toISOString(),
});
return order;
}
A subscriber reacting independently, in a different service:
eventBus.subscribe("order.placed", async (event) => {
await inventoryService.reserveStock(event.items);
});
Core Event-Driven Architecture Concepts Every Developer Should Know
Events describe facts that already happened, not commands. order.placed is an event (a fact); reserve-inventory would be a command (an instruction). This distinction matters — an event's publisher shouldn't know or care who's listening or what they'll do, while a command implies a specific expected action from a specific recipient.
Eventual consistency is a fundamental tradeoff, not an edge case. Since subscribers process events asynchronously, there's a window where the system is in a transiently inconsistent state (the order exists, but inventory hasn't been reserved yet) — designing for this explicitly, rather than assuming synchronous-style immediate consistency, is core to building correct event-driven systems.
At-least-once delivery is the common guarantee, which means consumers must handle duplicate events. Most message brokers guarantee a message is delivered at least once, not exactly once — a consumer might see the same event twice due to retries or broker behavior, so idempotent event handling (the same idempotency principle as API requests) is essential, not optional.
Event schema evolution needs deliberate versioning. As services evolve, event shapes change — publishers and subscribers are deployed independently, so a breaking schema change can silently break subscribers that haven't been updated yet. Fix this with explicit schema versioning and backward-compatible changes wherever possible.
Common Event-Driven Architecture Mistakes and How to Fix Them
Mistake 1: not handling duplicate event delivery, assuming exactly-once delivery when most brokers only guarantee at-least-once. Fix: make event handlers idempotent, using an event ID to detect and skip already-processed events.
Mistake 2: making breaking changes to event schemas without versioning, silently breaking subscribers still expecting the old shape. Fix: version event schemas explicitly and maintain backward compatibility, or run parallel versions during a migration window.
Mistake 3: using events for operations that actually need synchronous confirmation (like validating payment before completing a purchase flow the user is actively waiting on), where eventual consistency's inherent delay is genuinely the wrong fit. Fix: recognize which operations need synchronous confirmation and use direct API calls for those, reserving events for genuinely asynchronous, decoupled reactions.
When Should You Use Events Instead of Direct API Calls?
Use events when a service's action needs to trigger reactions in multiple, potentially unknown-in-advance subscribers, and those reactions don't need to complete before the originating action can be considered successful. Use direct API calls (synchronous) when the caller genuinely needs an immediate, confirmed result before proceeding — anything the user is actively waiting on with a clear success/failure branch.
Event-Driven Architecture in Production
Design every event handler to be idempotent from the start, since at-least-once delivery is the realistic guarantee you'll be operating under, not exactly-once. Also invest in schema versioning discipline early, since retrofitting it after multiple independently-deployed services already depend on an unversioned event shape is a much harder migration than starting with it.
If your services currently communicate through a tangle of direct synchronous calls that couple their availability together, event-driven architecture is worth evaluating specifically for the parts of that system where the coupling is causing real operational pain.