Part 2. The philosophy in a nutshell

Part 1 took a comprehensive look at what it means for a system to be Reactive. You saw how the requirement to always react to user input entails resilience and scalability in order to retain responsiveness even during failures and varying load conditions. Throughout our exploration of these desirable properties, you encountered the need for the underlying implementation to be message-driven.

Part 2 complements the description of the four Reactive traits: it presents a set of building blocks from which a Reactive architecture can be constructed. Where part 1 described what we want to achieve and why, this part focuses on how to do it. The guiding principles developed here, together with the tools of the trade introduced in chapter 3, form the foundation on which the patterns in part 3 are built.

We decided to present the material in a contiguous, cohesive fashion so that it can serve as a compact reference when you are gauging the design of your own patterns that you develop as you build Reactive applications. As a 360-degree view of a fully reactive architecture, this part covers a lot of ground. You may want to read chapter 4 and then skim the rest of this part, returning to it after you have studied the corresponding patterns in part 3 of this book.

In this part, you will learn about the following: