Chapter 8. Event-driven architecture with Spring Cloud Stream

When was the last time you sat down with another person and had a conversation? Think back about how you interacted with that other person. Was it a totally focused exchange of information where you said something and then did nothing else while you waited for the person to respond in full? Were you completely focused on the conversation and let nothing from the outside world distract you while you were speaking? If there were more than two people in the conversation, did you repeat something you said perfectly over and over to each conversation participant and wait in turn for their response? If you said yes to these questions, you have reached enlightenment, are a better human being than me, and should stop what you’re doing because you can now answer the age-old question, “What is the sound of one object clapping?” Also, I suspect you don’t have children.

8.1. The case for messaging, EDA, and microservices

8.1.1. Using synchronous request-response approach to communicate state change

8.1.2. Using messaging to communicate state changes between services

8.1.3. Downsides of a messaging architecture

8.2. Introducing Spring Cloud Stream

8.2.1. The Spring Cloud Stream architecture

8.3. Writing a simple message producer and consumer

8.3.1. Writing the message producer in the organization service

8.3.2. Writing the message consumer in the licensing service

8.3.3. Seeing the message service in action

8.4. A Spring Cloud Stream use case: distributed caching

8.4.1. Using Redis to cache lookups

8.4.2. Defining custom channels

8.4.3. Bringing it all together: clearing the cache when a message is received

8.5. Summary