Key Considerations and Best Practices for Using Spring Event in Backend Systems

Today we focus on the most critical issues when using Spring Event, based on real production‑environment experience.

Spring Event implements an event‑based publish‑subscribe mechanism; developers can define custom events, publish them, and Spring broadcasts them to listeners that implement ApplicationListener or are annotated with @EventListener .

1. Why must a business system implement graceful shutdown before using Spring Event?

When Spring broadcasts a message, it looks up all listeners in the ApplicationContext by calling getBean . During the shutdown of ApplicationContext , calling getBean is prohibited and will throw an error ("Do not request a bean from a BeanFactory in a destroy method implementation").

In our production system, high traffic caused a few requests to arrive during shutdown, leading to exceptions when Spring attempted to publish events.

Therefore, before using Spring Event, ensure that all inbound traffic (HTTP, MQ, RPC) is cut off, then shut down the Spring context.

2. Why are events lost during the service startup phase?

Our Kafka consumer started in the init-method before the @EventListener registrations were completed, so events published by the consumer could not find any listeners.

The solution is to open inbound traffic only after Spring has fully started, e.g., by registering services in a SmartLifecycle bean or listening to ContextRefreshedEvent .

3. Business characteristics suitable for publish‑subscribe

Event publishers do not care how events are processed.

Event publishers do not care about processing results.

Multiple subscribers can handle events synchronously or asynchronously.

Subscribers are independent and do not depend on each other.

Publish‑subscribe is not suitable for strong‑consistency scenarios where a failure must trigger a rollback.

4. Strong‑consistency scenarios are unsuitable for Spring Event

In order‑placement workflows, inventory deduction and order creation must be atomic. If a subscriber fails, Spring Event cannot propagate the failure to trigger a rollback, making it inappropriate for such use cases.

5. Eventual‑consistency scenarios are ideal for Spring Event

After an order is successfully placed, downstream actions such as sending MQ messages or releasing locks can be handled by Spring Event, because the core transaction has already succeeded and these follow‑up actions only need to be eventually consistent.

6. Ensure reliability when using Spring Event

Three approaches are recommended:

Subscriber‑side retry (e.g., using @Retryable to automatically retry on exceptions).

Kafka consumer retry – let Kafka re‑deliver failed messages or move them to a dead‑letter queue.

Report unrecoverable failures to a fault‑management platform, which can trigger manual or automated retries.

Example of a retryable subscriber:

@Retryable(value = Exception.class, maxAttempts = 3, backoff = @Backoff(delay = 100L, multiplier = 2))
public void performSuccess(PerformEvent event) {
    // business logic
}

Dependency required:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.4.RELEASE</version>
</dependency>

7. Subscribers must be idempotent

Because retries re‑execute all subscribers, each subscriber’s logic must be idempotent to avoid data inconsistency.

8. Why use Spring Event even when MQ exists?

MQ is powerful for inter‑service communication, while Spring Event is lightweight and ideal for intra‑application decoupling. Both can coexist: use MQ for cross‑service events and Spring Event for internal, fine‑grained publish‑subscribe needs.