Data

The topics of single responsibility, independent DURS, bounded context, and isolation come up over and over again in the context of microservices. I cover these topics at length in this book as well. The topic of a database per service also comes up over and over again in the same context. It's the combination of these topics that is rarely covered, though that is beginning to change. Earlier in this chapter, we discussed the critical idea of turning the database inside out and in turn how the cloud is the database. Bounded isolated data, as a part of the whole of a component, is fundamental to building cloud-native systems that are responsive, resilient, and elastic. Unfortunately, there is a tendency to gravitate toward shared monolithic databases. This is in part because that is the way it has always been. The other reason for this tendency towards monolithic databases is that managing and operating a database in the cloud at a large scale is hard. Managing a sharded database is more difficult and managing Polyglot Persistence is even more difficult. We have already covered this briefly, but as a core tenet of this book it bears repeating.

The result of this shared monolithic database model is that we have no bulkheads for our data. More and more tables are added to the monolithic database, ever increasing the probability that these tables will be competing for the same, scarce resources. In the best case, the database requests only increase in latency as they compete for the available memory, I/O throughput, and CPU cycles. Or worse, lack of disk space causes the database to crash and results in an outage across the entire system. Ultimately, if we have no isolation at the persistence layer then we effectively have no isolation at the component layer. Instead, each component must have its own isolated databases. Taking this one step further, we discussed how mature cloud-native systems are multi-regional, because they need to be resilient to regional outages. This means that mature cloud-native data must also be multi-regional. Thus, the persistence layer is an example of where we need a different way of thinking and reasoning about software architecture.