Event-Driven Microservices
Connect services through a broker with Spring Cloud Stream, so they communicate by events, not brittle direct calls.
On this page
In the Reactive & Messaging module you learned brokers - Kafka and RabbitMQ. In a microservice system, event-driven communication becomes the preferred way for services to talk, because direct calls make services brittle and tightly coupled. Spring Cloud Stream gives you a broker-agnostic way to wire services together with events.
Events over direct calls
Recall the trade-off from the resilience lesson: if lending calls notification directly and notification is down, lending suffers. Publish an event instead, and lending doesn't care who's listening or whether they're up right now - the broker holds the event until they are:
// producer: lending emits an event
@Bean
Supplier<BookBorrowedEvent> bookBorrowed() { ... }
// consumer: notification reacts, in a separate service
@Bean
Consumer<BookBorrowedEvent> handleBorrow() {
return event -> sendNotification(event);
}Spring Cloud Stream binds these Supplier/Consumer/Function beans to broker destinations
(a Kafka topic or RabbitMQ queue) via configuration - so your code is just plain functions, and
the wiring is external.
Broker-agnostic by design
The same functional code runs on Kafka or RabbitMQ by swapping a binder dependency and some config - you don't rewrite your producers and consumers. That means you can choose (or change) the broker without touching business logic.
You don't hard-wire a lamp directly into another lamp; you plug both into the mains, and they work regardless of what else is plugged in. Spring Cloud Stream is the mains socket for services: each publishes to or consumes from shared destinations through a standard "plug" (the binder), so services connect through the broker rather than wiring directly to each other.
The same event, now distributed
BookVault's in-process BookBorrowedEvent from the messaging module is the seed of this. As a
microservice, lending publishes that event to a broker via Spring Cloud Stream, and a separate
notification service consumes it. The event you designed in-process scales straight out to
services - which is exactly why you learn event-driven thinking before distributing.
As a monolith, BookVault's borrow publishes an in-process event a notifier handles. Split into a lending service and a notification service, describe how Spring Cloud Stream connects them, and one resilience benefit versus lending calling notification directly over HTTP.
What does Spring Cloud Stream provide for microservices?
Key takeaways
- In microservices, event-driven communication is preferred over direct calls, which couple services and spread failure.
- Spring Cloud Stream binds Supplier/Consumer/Function beans to broker destinations via config, so business code stays plain functions.
- It's broker-agnostic: the same code runs on Kafka or RabbitMQ by swapping a binder and config.
- Publishing events decouples producers from consumers in time - a down consumer doesn't fail the producer; the broker holds the event.
- An in-process application event scales straight out to a distributed event via Cloud Stream.