The Limits of Spring Events: Why Microservices Demand Durable and Reliable Messaging

What if I told you the Spring Event logic you just wrote, the code you believe is clean and decoupled, is actually a poison slowly sickening your entire system? This is the harsh reality of the limits of Spring Events when applied outside of a monolith. Inside a single application, Spring Events are a vitamin. But the moment they are used to connect microservices, they become a slow-acting poison that guarantees silent data corruption.

The worst part? The system appears perfectly healthy. There are no alarms, no exceptions—until a customer’s order vanishes after a simple server restart. By then, it’s too late. This article will serve as the antidote. We will dissect this “poison,” revealing exactly how its in-memory nature leads to inevitable failure, and equip you with the only cure: a robust architecture built on durable and reliable messaging.

The JVM Boundary: Local Events Only

The most fundamental limitation is that Spring Events are strictly local to the Java Virtual Machine (JVM) in which they are published. The mechanism relies on the Spring ApplicationContext where the publisher and listeners reside.

In a microservice architecture, the OrderService and InventoryService run in separate processes, often on different machines.

[Order Service (JVM 1)]                                     [Inventory Service (JVM2)]
         |                                                              |
    publish Event  ---> Spring Context 1                                |
         |                                                              |
         X------------------------(Can't Cross Network)-----------------X

Spring Events have no mechanism to serialize an event, transmit it over the network, and deserialize it in another service. They are simply not designed for distributed communication.

Volatility: The Danger of In-Memory Events

The most critical risk when using Spring Events for essential business processes is their volatile nature. Spring Events reside only in the application’s memory (RAM). They are not persisted to disk.

This volatility becomes particularly dangerous when using asynchronous processing (@Async) or post-commit events (@TransactionalEventListener(phase = AFTER_COMMIT)).

Consider this common pattern:

@Service
public class OrderService {
    
    @Transactional
    public Order placeOrder(OrderCommand command) {
        Order order = repository.save(new Order(command));

        // Event is published, but listeners might wait for commit

        eventPublisher.publishEvent(new OrderPlacedEvent(order.getId()));
        return order;
    }
}

@Service
public class NotificationService {
    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleOrderPlaced(OrderPlacedEvent event) {
        // Send confirmation email asynchronously
    }
}

Let’s analyze the execution flow and the failure window:

1. The OrderService transaction successfully commits. The database state is permanently changed.
2. Spring intercepts the commit and prepares the event for the asynchronous listener. The event is placed in an in-memory queue (managed by the TaskExecutor).
3. CRASH: Before the asynchronous thread picks up the event and executes the NotificationService, the application crashes (e.g., OOM error, hardware failure, pod restart).

When the application restarts, the in-memory queue is gone. The order exists in the database, but the notification event is lost forever. This leads to system inconsistency.

Delivery Guarantees: At-Most-Once

The volatility issue directly translates to a weak delivery guarantee. Spring Events provide At-Most-Once delivery.

• At-Most-Once: An event is delivered zero or one time. It might be lost, but it will never be duplicated.

For core business transactions, this guarantee is insufficient. The typical requirement is for At-Least-Once delivery, ensuring an event is processed even if it requires retries.

Spring Events offer no built-in mechanisms for:

• Persistence: Storing the event until it is successfully processed.
• Retries: Automatically retrying the listener if processing fails due to a transient error (e.g., the SMTP server is temporarily unavailable).
• Dead-Letter Queues (DLQ): Moving events that consistently fail processing to a separate location for inspection.

The Solution: Durable Messaging and Message Brokers

To overcome these limitations, distributed systems require a Durable Messaging solution, typically implemented using a Message Broker (such as Apache Kafka, RabbitMQ, or ActiveMQ).

A Message Broker is an intermediary infrastructure component that provides critical capabilities:

• Durability: Brokers immediately persist incoming messages to disk. If a crash occurs, messages can be recovered.
• Network Transparency: Brokers use standard network protocols to facilitate communication between services regardless of their location or technology stack.
• Reliability (At-Least-Once): Consumers acknowledge (ACK) a message only after successful processing. If an acknowledgment is not received, the broker redelivers the message.

[ Order Service ]                                              [ Inventory Service ]
        |                                                                 |
        |------(Produce)------>[ Message Broker ]------(Consume/ACK)----->|

The New Challenge: The Dual Write Problem

Introducing a Message Broker solves the problems of volatility and the JVM boundary. However, it introduces a new, critical challenge in distributed systems: The Dual Write Problem.

The core requirement is that the business transaction (saving the order to the database) and the event emission (sending the event to the broker) must happen atomically. Either both succeed, or both fail; it cannot be possible to have one without the other.

Consider this naive implementation using Kafka:

public Order placeOrder(OrderCommand command) {
    // 1. Transaction scope
    Order order = transactionTemplate.execute(status -> {
        return repository.save(new Order(command));
    });
    // <-- Transaction Committed Here

    // !!! DANGER ZONE !!!

    // 2. Send to Message Broker
    kafkaTemplate.send("order-topic", new OrderPlacedEvent(order.getId()));

    return order;
}

If the application crashes in the “DANGER ZONE”—after the database commits but before the message broker receives the event—the system is again inconsistent. The order is saved, but the event is lost.

It is not possible to reliably coordinate a transaction between two different resources (the relational database and the message broker) without resorting to complex and often discouraged protocols like Two-Phase Commit (2PC/XA), which severely impact performance and availability.

Conclusion

Spring Events are a powerful tool for implementing the Observer pattern within a single JVM boundary. However, their in-memory nature, lack of delivery guarantees (At-Most-Once), and inability to cross process boundaries make them unsuitable for reliable communication in a microservice architecture.

Building resilient, distributed EDA systems demands the adoption of durable messaging solutions provided by Message Brokers. While this solves the reliability issue, it introduces the critical challenge of maintaining atomicity between database state changes and event emission—the Dual Write problem.

The next post will introduce the Transactional Outbox Pattern, an elegant solution to the Dual Write problem that guarantees data consistency and reliable event delivery without relying on 2PC.