Introduction to event-driven microservices with Spring Cloud Stream

Spring Cloud Stream framework allows to easily include well-known Spring patterns and best practices to applications while implementing event-driven microservices architecture. It uses Spring Integration project to provide connectivity to a message broker. It provides built-in support for such features like persistent publish-subscribe model, consumer grouping and partitioning. The integration with specific message broker solution is realized by binder implementations that are hidden behind middleware-neutral core.The currently described version of Spring Cloud Stream is 3.0.3.RELEASE within Spring Cloud Release Train Hoxton.SR3.

For more detailed introduction to a process of building microservices-based architecture with Spring Cloud Stream you can refer to my video course: Microservices With Spring Boot And Spring Cloud: Part 5 – Event-driven microservices.


Our sample system consists of three microservices producer-service, consumer-a-service, and consumer-b-service. Each of them is connecting with RabbitMQ broker. The application producer-service is responsible for sending events to a message broker, while two other microservices are listening for the incoming events. Communication between applications follows a publish-subscribe model, where data is broadcast through shared topics. Our consumer application are enabling such mechanisms like consumer grouping to guarantee that only a single instance of application is handling the same event, and partitioning for assigning events to the selected instance of application basing on routing key set on the producer side. The following picture is visualizing a currently described architecture.


The source code of sample applications is as usual available on GitHub. You may find it in the repository That repository also contains code snippets of applications used in previous parts of my video course, so you should go to directory event-driven to access the right samples.


To enable Spring Cloud Stream for our application we first need to include the right binder implementation library. Because we are integrating with RabbitMQ we have to use spring-cloud-stream-binder-rabbit artifact. It is referencing to all other required libraries, so we don’t have to include any other dependencies.



Each message that is sent to message broker is automatically serialized to JSON. Here’s a class that is the object representation of JSON payload exchanged by the applications.

data class CallmeEvent(val id: Int = 0, val message: String = "")

Producer application

Here’s the implementation of Supplier bean responsible for generating a stream of events continuously. By default it is sending CallmeEvent once a second. It is incrementing id field on every new event and set header to_process to true. Basing on the value of this header we are routing messages on the consumer side. The mechanism may be easily disabled by setting property callme.supplier.enabled to false.

class ProductionApplication {

    var id: Int = 0

    val supplierEnabled: Boolean = false

    fun callmeEventSupplier(): Supplier<Message<CallmeEvent>?> = Supplier { createEvent() }

    private fun createEvent(): Message<CallmeEvent>? {
        return if (supplierEnabled)
            MessageBuilder.withPayload(CallmeEvent(++id, "I'm callme event!"))
                    .setHeader("to_process", true)

Alternatively we may send an event on demand, for example by calling REST endpoint. To do that we need to use StreamBridge bean. It provides send method that takes a name of binding and message object as parameters. We may set just a payload object or use MessageBuilder to create the whole GenericMessage with headers. Our controller is exposing two POST methods. First of them POST /{message} is used just for setting message body. The second method POST /{message}/process/{process} allows set header to_process.

class ProducerController(val streamBridge: StreamBridge) {

    var id: Int = 0

    fun sendEvent(@PathVariable message: String): Boolean {
        return streamBridge.send("callmeEventSupplier-out-0", CallmeEvent(++id, message))

    fun sendEventWithHeader(@PathVariable message: String, @PathVariable process: Boolean): Boolean {
        return streamBridge.send("callmeEventSupplier-out-0",
                MessageBuilder.createMessage(CallmeEvent(++id, message),
                        MessageHeaders(mutableMapOf(Pair<String, Any>("to_process", process)))))

Here is a configuration file of our application. We need to a default name of destination for our binding (1). By default it is the same as a binding name, but we are going to change it to callme-events. The same destination will be set on the consumer side. If we are using StreamBridge for sending messages we also need to set property with the name that is used as a prefix of generated binding name. If you would like to use the same output as for Supplier you should set the same name as for method that registers Supplier bean – callmeEventSupplier. We should also increase a level of logging for Spring AMQP library to see the structure of messages sent to message broker (3). #(1) #(2) #(3)

Consumer application

There are two different applications that listen for incoming events. Let’s start from implementation of consumer-a-service. It is pretty simple, because it is just logging message that has been consumed from callme-events topic. To consume message from destination we need to define Consumer bean that takes CallmeEvent as an argument.

class ConsumerAApplication {

    val logger: Logger = LoggerFactory.getLogger(

    fun callmeEventConsumer(): Consumer<CallmeEvent> = Consumer {"Received: {}", it) }

In the application properties we also need to override a default name of destination for callmeEventConsumer-in-0 binding. That name is the same as name of output destination configured on the producer side – callme-events. We are also setting a consumer group for all instances of consumer-a-service application. The name of group is a. Consumer group guarantees that only a single instance of application in a group is handling a single incoming event.

Message broker

We are running RabbitMQ on Docker container. We need to expose two ports outside container: 5672 for TCP connections from applications and 15672 for web management console. The following command starts the container.

$ docker run -d --name rabbit -h rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management

Now, we may run both our applications producer-service and consumer-a-service. We are going to run a single instance of producer-service and two instances of consumer-a-service. After that producer-service is starting to send events continuously to the destination on message broker. We may verify it with Rabbit Management Console. To login use default guest / guest credentials.


Routing function

We can provide some more advanced routing on the consumer side. In Spring Cloud Stream nomenclature event routing is the ability to either route evens to a particular even subscriber or route event produced by an event subscriber to a particular destination. Event routing may be enabled for application by setting property to true. After that the generated name of bindings is automatically set to functionRouter-*.
I enabled event routing feature for consumer-b-service. Here’s the list of configuration properties required to enable routing for consumer listening on callme-events destination. When enabling event routing we also need to set a routing expression. We may use SPeL notation for it. In that case I’m performing routing basing on to_process header value.['to_process']!=null && headers['to_process']==true) ? 'process':'fireForget'

The name of declared Consumer or Function beans should be the same as the values returned by In that case these are fireForget() and process().

class ConsumerBApplication {

    val logger: Logger = LoggerFactory.getLogger(

    fun fireForget(): Consumer<CallmeEvent> = Consumer {"Received(fireForget): {}", it) }

    fun process(): Function<CallmeEvent, CallmeResponse> = Function { logAndResponse(it) }

    private fun logAndResponse(callmeEvent: CallmeEvent): CallmeResponse {"Received(process): {}", callmeEvent)
        return CallmeResponse(, "I'm callme response")

Here’s the list of exchanges used by our system after starting consumer-b-service. Since the name of destination for functionRouter-in-0 is overridden in configuration properties, the name of destination for functionRouter-out-0 is left at its default value.



Partitioning is a critical concept in stateful processing, where it is required to ensure that all related data is handled together. So, thanks to partitioning we may implement an algorithm responsible for distributing messages across multiple instances of applications in determined way.
To enable partitioning on the producer side we need to set two properties related with a given binding. It is producer’s partitionKeyExpression, which in that case the id field of CallmeEvent, and producer’s partitionCount with a number of partitions. This number should be the same as a number of running instances of application, since each partition is assigned to the selected instance of that application. Because we are planning to run two instance, we are setting such a value.

To enable partitioning on the consumer side we need to enable a single property on a given binding. We
also need to set a property using the static number that represents a number of deployed instances of an application. While Kafka supports more flexible way of partitioning configuration, RabbitMQ requires a static value, so we can’t scale up number dynamically without changing these properties. We also need to set property for a single instance. It needs to 0 or 1 if we have two running instances as shown below.


Now we take a look on structure of routing inside callme-events exchange created on RabbitMQ. There are two consumers listening for incoming events per a single consumer group. So if we have to different consumer groups defined there 4 consumers in total. Within each group we have two different routing keys set for each target queue.


We can also verify that there are four queues that receive incoming events.



Spring Cloud Stream provides an easy way of testing your microservice applications without need to connecting to an external messaging system. To enable that support we need to include the following dependency to Maven pom.xml.


In JUnit test class we should import TestChannelBinderConfiguration class. after that we may use InputDestination for sending test messages, and OutputDestination for receiving them during a test. The following testRouter is created for consumer-b-service, and it verifies that RouterFunction is working properly by receiving and validating message sent to an output destination.

@SpringBootTest(classes = [ConsumerBApplication::class])
class RouterFunctionTest {

    lateinit var inputDestination: InputDestination
    lateinit var outputDestination: OutputDestination

    fun testRouter() {
        inputDestination.send(MessageBuilder.withPayload(CallmeEvent(1, "I'm callme event"))
                .setHeader("to_process", true)
        val response = outputDestination.receive()
        val payload = String(response.payload)
        val payloadObject = ObjectMapper().readValue(payload,
        Assertions.assertEquals("I'm callme response", payloadObject.message)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.