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:
- Enabling encapsulation and isolation with explicit asynchronous message passing
- Improving compositionality and adding horizontal scalability with location transparency
- Structuring your system in hierarchical modules following divide et regna[1]Latin: literal translation is “divide and reign;” commonly translated “divide and conquer.”
- How this hierarchy allows principled failure handling
- Achieving sufficiently consistent program semantics in a distributed system
- Avoiding nondeterminism where possible and adding it where necessary
- Guiding application design based on the topology of its message flows