In the first chapter, I told the story of my first wow moment when I realized that we could run our presentation layer entirely from the edge with no servers. From that point on, I wanted to achieve the same level of scalability for the rest of the layers as well. Let's start this chapter with a continuation of that story.

Like many of you, for a significant chunk of my career, I implemented systems that needed to be database agnostic. The relational database was the standard, but we had to support all the various flavors, such as Oracle, MySQL, in-memory databases for testing, and so forth. Object relational mapping tools, such as Hibernate, were a necessity. We built large relational models, crammed the database schema full of tables, and then tossed the DDL over the fence to the DBA team. Inevitability, the schema would be deployed to underpowered...

It is easy enough to say that we will architecture cloud-native systems based on Reactive principles and leverage event streaming to ultimately turn the cloud into the database, but it is another thing entirely to show how the pieces fit together. There is a relatively small collection of proven patterns that can be leveraged as templates to build cloud-native systems that solve a wide variety of valuable problems. Many of these patterns may already be familiar, but have cloud-native twists.

Each pattern describes a solution to a specific problem in the context of cloud-native systems and addresses various forces, issues, and trade-offs. The patterns are interrelated and thus can be pieced together to build systems composed of bounded isolated components. There are many ways to document patterns. Martin Fowler has an excellent summary of various pattern forms...

We have defined the architectural vision for our cloud-native systems and enumerated the patterns used to build these systems. The next step is to decompose a system into bounded isolated components. However, “What is the right size?” is a fundamental question that everyone asks. Ultimately, every team has to answer this question for itself. You have to ask yourself how confident you are that you can continuously deploy and scale each component. If you cannot be certain of the implications of a given change to a component then the component is potentially too large. If you have to make compromises on the scalability and tuning of a specific component then it likely needs to be split apart. If the backlog of changes to a component starts to clog then this is an indication that it may need to be refactored into multiple components. The potential...

In this chapter, we learned that cloud-native systems are built on the principles of Reactive architecture. We use asynchronous, message-driven, inter-component communication to build resilient components that are responsive and elastic. Event streaming is the mechanism for inter-component communication. Components publish domain events to notify the system of their state changes. Other components consume these events to trigger their behavior and cache pertinent information in materialized views. These materialized views make components responsive by providing a dedicated cache that is continuously warmed. They act as bulkheads to make components resilient to failures in upstream components, because the latest known state is available in local storage. This effectively turns the cloud into the database by leveraging value-added cloud services, turning the database inside...