1.1 Overview

“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” Leslie Lamport

This is one of those stories you hear a lot in distributed systems circles. A fast-growing e-commerce company had a solid Black Friday plan: scale up the payment service to handle the traffic spike. They did. It worked. Then their inventory service, which nobody had thought to scale, started struggling under thousands of concurrent stock checks.

Within minutes, the payment service started timing out waiting for inventory responses. Order confirmations stopped going out. The entire checkout flow went down. One service’s bad day had become everyone’s worst day.

The team hadn’t done anything obviously wrong. They’d followed the standard playbook: split the monolith into microservices, connect them with REST calls. The problem wasn’t the split. It was how they connected the pieces.

Read on.

By the end of this chapter, you’ll understand: - Why monoliths break down at scale, and why that’s not the monolith’s fault - Why synchronous microservices often make things worse, not better - What “thinking in events” actually means in practice - When event-driven architecture solves real problems, and when it creates new ones - What separates EDA from messaging and reactive programming

1.2 The Monolith: A Love Story

The monolith gets a bad reputation it doesn’t deserve.

When you’re building an e-commerce platform from scratch, a monolith is the right call. One codebase, one deployment, one database. Your OrderService calls your PaymentService as a method call, not a network request. No timeouts. No serialization. No service discovery. It either works or it throws an exception, and you find out immediately.

Here’s what a simple e-commerce monolith looks like:

@Service
public class OrderService {

    private final PaymentService paymentService;
    private final InventoryService inventoryService; // (1)

    public Order placeOrder(OrderRequest request) {
        inventoryService.reserve(request.getItems()); // (2)
        paymentService.charge(request.getPayment());  // (3)
        return orderRepository.save(new Order(request));
    }
}

(1) Both services are Spring beans: no HTTP, no Kafka, just Java method calls

(2) Each call is synchronous and within the same transaction: if payment fails, inventory rolls back automatically

(3) Payment runs in the same transaction: a failure here rolls back both the payment and the inventory reservation

This is clean. This is simple. When something goes wrong, your stack trace tells you exactly where. Your database transaction handles consistency for free. You deploy one JAR and go home.

I’ve seen teams rewrite a perfectly good monolith into microservices and spend six months rebuilding functionality they used to take for granted: transactional consistency, integrated testing, a single place to search for logs. The monolith wasn’t the problem.

Scale was.

The monolith’s strength is also its weakness: everything runs in the same process. When your codebase grows, when your team grows, when your traffic grows, that single process becomes a liability. Understanding why is more important than just knowing that it does.

So what exactly breaks down?

1.3 When the Monolith Starts to Hurt

The monolith doesn’t fail dramatically. It degrades slowly, and then all at once.

There are three distinct failure modes. Each one feels manageable in isolation. Together, they make the monolith untenable at scale.

The scale problem. Every component in a monolith scales together. Your checkout flow is under heavy load? You scale up the entire application, including the reporting module nobody is using. Worse, a slow database query in one feature doesn’t just slow down that feature. It blocks a thread. Block enough threads and the entire application stalls.

When a thread blocks on a database call or an HTTP request, it holds its slot in the thread pool idle. It does nothing, but it also cannot be reused. Other incoming requests queue behind it. Once the pool is exhausted, the server stops accepting new work. It does not crash. It does not log an error. It just stops responding, and the only signal is a growing pile of timed-out requests in your monitoring.

This is one of the most common stories in distributed systems. A team adds a feature that generates a slow, expensive report. The report runs fine in isolation. Under load, it competes for database connections with the checkout flow. Black Friday arrives. Checkouts slow to a crawl, not because of anything wrong with the checkout code, but because a reporting query is holding a connection pool hostage.

The team problem. A monolith with four teams is four teams fighting over the same codebase. A change in the payment module requires a full application deployment. That deployment is now everyone’s concern: the team that touched payments, the team that didn’t, and the release manager who has to coordinate them all.

At a certain team size, the coordination cost of a monolith exceeds the coordination cost of distributed services. That threshold is lower than most people expect. Once you have more than two or three teams, a shared codebase starts creating more friction than it saves.

The reliability problem. In a monolith, one broken component can take down everything else. A memory leak in the notification module eventually crashes the JVM. The order service goes with it. Not because anything is wrong with orders, but because they share a process.

The instinct at this point is correct: these services need to be independent. They shouldn’t share a process, a deployment, or a failure domain. The question is how to make them independent without creating a different set of problems.

The obvious answer is microservices. And it works, until it doesn’t.

Migration approach: The strangler fig pattern is the most practical path from monolith to event-driven microservices. Rather than rewriting everything at once, you extract one bounded context at a time. Route new traffic to the new service, leave existing traffic on the monolith until the new service proves stable, then cut over. Kafka makes this tractable: the new service can consume events from Debezium (CDC) on the legacy database without requiring any changes to the monolith itself.

So what goes wrong?

1.4 The Microservices Escape (And Its New Problems)

Splitting the monolith feels like the right move. And it is, if you do it carefully.

The natural approach is to extract services and connect them with REST calls. OrderService calls PaymentService over HTTP. PaymentService calls InventoryService. Each service has its own database, its own deployment, its own team. Independence achieved.

Except it isn’t.

// OrderService - the naive microservices approach
public Order placeOrder(OrderRequest request) {
    inventoryClient.reserve(request.getItems());  // (1)
    paymentClient.charge(request.getPayment());   // (1)
    return orderRepository.save(new Order(request));
}

(1) These are now HTTP calls: synchronous, blocking, and dependent on two external services being up and healthy

This looks almost identical to the monolith version. The difference is invisible until something goes wrong.

The cascading failure problem. When OrderService calls PaymentService synchronously, it waits. If PaymentService is slow, OrderService is slow. If PaymentService is down, OrderService is broken. You’ve distributed the deployment but kept the coupling. This is the distributed monolith: the worst of both worlds.

Think of it like a chain of phone calls. If everyone in the chain needs an answer before they can continue, one slow person halts the entire conversation. The only way to avoid that is to stop waiting for answers in real time.

The latency chain problem. Every synchronous hop adds latency. OrderService calls PaymentService (50ms) which calls FraudService (30ms) which calls a third-party API (200ms). Your order placement is now 280ms minimum, and that’s when everything is healthy. Add retries, add timeouts, and you can easily hit seconds.

The distributed transaction problem. In the monolith, a database transaction covered everything. In microservices with separate databases, there’s no such safety net. If InventoryService reserves stock and then PaymentService fails, you have reserved inventory for an order that never completed. Cleaning that up manually is painful. Preventing it is a design challenge that requires patterns we’ll spend several chapters on.

Going Deeper: The “distributed monolith” anti-pattern is described in depth in Sam Newman’s Building Microservices. If you’re mid-migration from a monolith and recognize this pattern in your system, that book is worth reading alongside this one.

Microservices with synchronous REST calls don’t remove coupling. They move it from compile-time to runtime and make it harder to see. The services are independently deployable in theory, but in practice, a failure in one still brings down others.

There’s a different way to think about this. What if services didn’t call each other at all?

1.5 Thinking in Events

The shift to event-driven architecture is less a technical change and more a change in how you think about communication between services.

In a synchronous system, a service calls another service. It says: “Do this. Wait for the result.” The caller and the callee are coupled in time. Both must be available simultaneously, and the caller blocks until the response arrives.

In an event-driven system, a service announces that something happened. It says: “This occurred.” Then it moves on. It doesn’t know who’s listening. It doesn’t wait for a response. It doesn’t care whether the downstream service is currently running.

This is the core idea. Everything else follows from it.

Events are facts, not requests. An event is something that happened, immutable and past tense. OrderPlaced. PaymentProcessed. InventoryReserved. You don’t send an OrderPlaced event and then change your mind. The order was placed. That’s a fact now. This immutability is what makes events a reliable foundation for distributed systems.

Producers don’t know consumers. When OrderService publishes an OrderPlaced event, it has no idea that PaymentService is listening. It also doesn’t know that NotificationService is listening to send a confirmation email, or that AnalyticsService is listening to track the conversion. You can add a new consumer without touching the producer at all.

This is true decoupling. Not just independent deployments, but independent existence.

The diagram below shows the difference:

In the REST model, OrderService has direct dependencies on both PaymentService and InventoryService. A failure in either affects OrderService directly.

In the event-driven model, OrderService publishes to a topic. PaymentService and InventoryService consume from it independently. OrderService doesn’t know they exist, and doesn’t need to.

The mental shift required here is real. We’re trained to think in terms of function calls: invoke this, get that back. Event-driven thinking inverts the control flow. Instead of asking “who do I need to call?”, you ask “what just happened, and who might care?”

That reframing changes the design of your entire system.

Order.DraftCreated
Order.ItemsValidated
Order.PriceCalculated
Order.PaymentInitiated
Order.PaymentCaptured
Order.Confirmed

// Internal domain event - never publish this on a shared topic
record OrderPaymentCaptured(
    String orderId,
    String internalTransactionRef,   // internal ID, meaningless outside
    String paymentGatewayCode,       // internal status code
    BigDecimal capturedAmount,
    Instant capturedAt
) {}

// Integration event - this is what other services consume
record OrderConfirmed(
    String orderId,
    String customerId,
    BigDecimal totalAmount,
    Instant confirmedAt
) {}

1.6 EDA vs Messaging vs Reactive: Clearing the Confusion

Three terms get used interchangeably in this space. They’re related, but they’re not the same thing. Getting this straight now will save confusion for the rest of the book.

Event-Driven Architecture (EDA) is an architectural style. Services communicate by producing and consuming events. No direct calls. No shared state. The events represent things that happened in your domain: OrderPlaced, PaymentFailed. EDA is the what and why of this book.

Message-Driven (or Message-Oriented) architecture is related but subtly different. In message-driven systems, services send commands, which are instructions for another service to do something. ProcessPayment. ReserveInventory. These are requests, not facts. The sender has intent; it wants something done. Messaging systems (like JMS or RabbitMQ) are often used this way.

The distinction matters because commands create coupling. If you send a ProcessPayment command, you’re implicitly depending on a payment processor being there to handle it. Events don’t carry that assumption. They just report what happened.

Reactive programming is a programming model: a way of writing code that deals with asynchronous data streams. Project Reactor, RxJava, Spring WebFlux are reactive programming frameworks. You can use reactive programming without EDA, and you can do EDA without reactive programming.

Think of it this way: - EDA tells you how your services relate to each other - Messaging tells you what kind of thing they’re sending each other - Reactive tells you how you write the code that handles it

In this book, we’re doing EDA. We’ll use Kafka as the event backbone, Spring Boot as the application framework, and occasionally Spring’s reactive support where it makes sense. But the focus is always on the architectural patterns, not the reactive APIs.

With that cleared up, what does event-driven actually look like in code?

1.7 A Tale of Two Services

The best way to understand the difference between synchronous and event-driven is to see the same business logic written both ways.

The scenario: a customer places an order. We need to charge their payment method and reserve the inventory. Here’s how a synchronous implementation handles it, and here’s where it breaks.

// OrderService - synchronous approach
public Order placeOrder(OrderRequest request) {
    try {
        inventoryClient.reserve(request.getItems()); // (1)
        paymentClient.charge(request.getPayment());  // (2)
        return orderRepository.save(new Order(request));
    } catch (PaymentException e) {
        inventoryClient.release(request.getItems()); // (3)
        throw e;
    }
}

// OrderService - event-driven approach
public Order placeOrder(OrderRequest request) {
    Order order = orderRepository.save(
        new Order(request, OrderStatus.PENDING) // (1)
    );
    eventPublisher.publish(new OrderPlaced(order)); // (2)
    return order;
}

// PaymentService - listens independently
@KafkaListener(topics = "order-placed")
public void on(OrderPlaced event) {
    var result = paymentService.charge(event.orderId()); // (3)
    eventPublisher.publish(new PaymentProcessed(
        result.paymentId(), event.orderId(), result.amount(), result.currency(), Instant.now()));
}

1.8 When EDA Is the Right Choice (And When It Isn’t)

Event-driven architecture is not the right answer for every system. Applying it where it doesn’t belong adds complexity without benefit. Here’s how to think about the trade-off honestly.

1.9 Common Mistakes and Summary

1. Adopting EDA before you have the problems it solves. EDA is a solution to scale and coupling. If your team is small and your traffic is manageable, the operational overhead isn’t worth it yet.

2. Building a distributed monolith. Splitting services and keeping synchronous REST calls between them gives you the complexity of distribution without the benefits of decoupling. If services still call each other directly, you haven’t achieved independence.

3. Treating events like commands. Publishing a ProcessPayment event is not event-driven architecture. It’s messaging with extra steps. Events are facts: PaymentProcessed. Commands are instructions: ProcessPayment. The distinction changes how you design your consumers.

4. Ignoring eventual consistency in the UI. Event-driven systems are eventually consistent. If your frontend expects immediate confirmation of every action, you’ll have a mismatch between your architecture and your user experience. Design for it deliberately.

5. Underestimating the operational overhead. Kafka needs monitoring, schema management, consumer lag alerting, and disaster recovery planning. This is real work. Factor it into your decision.