While the preceding example is a simple communication between two applications, typical flows in real-world applications can be much more complex.

The following figure shows an example scenario involving the message flow across three different applications. The source application generates the event. The processor application processes the event and generates another message that will be processed by the sink application:

Another example scenario involves an event that is consumed by multiple applications. For example, when a customer is registered, we would want to send them an e-mail, a welcome kit, and a mail. A simple messaging architecture for this scenario is shown in the following figure:

To implement the preceding scenarios, a number of different steps are involved:

1. Configuring the message broker.
2. Creating different channels on the message broker.
3. Writing application code to connect to a specific channel on the message broker.
4. Installing necessary binders in the applications to connect to the message brokers.
5. Setting up the connection between the applications and the message broker.
6. Building and deploying the applications.

Consider a scenario where some of these applications in the flow have to process a huge load of messages. We would need to create multiple instances of such applications based on the load. The implementation complexity becomes multifold. These are the challenges that Spring Cloud Data Flow and Spring Cloud Stream aim to solve.

In the next section, we will look at how different Spring projects--Spring Cloud Stream (built on top of Spring Integration) and Spring Cloud Data Flow enable us to do message-based integrations with little configuration.