How do Spring application events (@EventListener, ApplicationEventPublisher) support decoupled, in-process communication?

Spring's built-in application event mechanism (ApplicationEventPublisher.publishEvent() + @EventListener, detailed under Spring Core & DI) is worth specifically distinguishing from external messaging (Kafka/RabbitMQ), since both solve a "decouple the producer from the consumer" problem but at very different scopes.

Application events are in-process only — they exist entirely within a single JVM/application instance's ApplicationContext. A UserRegisteredEvent published in one instance is only visible to @EventListener methods registered in that same instance; a separate instance of the same application (in a horizontally-scaled deployment) never sees it at all.

@Service
class UserService {
    private final ApplicationEventPublisher publisher;
    void register(User user) {
        // ... save user ...
        publisher.publishEvent(new UserRegisteredEvent(user.getId())); // visible only within this JVM
    }
}

When application events are the right tool:

• Decoupling side effects that only need to happen within the same application instance that triggered them — e.g., invalidating a local in-memory cache after an update, triggering a secondary in-process computation, or simply organizing code so unrelated concerns (sending a notification, writing an audit entry) aren't hard-wired directly into the primary operation's method body.
• No additional infrastructure (a message broker, network reliability concerns, serialization format) is needed at all — it's essentially free, using plain in-memory method dispatch under the hood.

When you need real messaging (Kafka/RabbitMQ) instead:

• The consumer needs to run in a different service or process entirely — application events never cross a JVM boundary, let alone a network boundary.
• You need durability — if no instance is currently running (or the instance crashes right after publishing), an application event is simply lost forever, with no persistence or replay; a message broker persists messages until they're actually consumed (and acknowledged).
• You need to scale consumers independently from producers, or have multiple different services (not just multiple listeners within one service) react to the same event.

Practical guidance: default to Spring application events for decoupling within a single service/instance — it's simpler, has zero extra infrastructure, and is easy to reason about; reach for an actual message broker only once the communication genuinely needs to cross process/service boundaries or requires durability guarantees an in-memory event can't provide.