Applied Akka Patterns

Chapter 8. Availability

One of the key requirements in reactive programming is that your system must provide availability. But what does it mean for a system to be available? We can consider a system available when it is able to respond to requests in a timely manner. If the system takes too long to respond, or in fact doesn’t respond at all, it is considered unavailable. A system is unavailable when it is down or overloaded.

Availability is distinct from the ability of the system to scale (e.g., scalability).

As detailed in Chapter 7, there are many things that can contribute to the system becoming unavailable. And no matter how much we try, there will be times when pieces of the system will become unavailable. The key, then, is to find ways to mitigate that, so that even in the face of failures, the system can remain available. We have already discussed how you can address specific types of failures. This chapter provides a higher-level look at how you can build systems in a way that supports availability, and what features Akka provides to get you there.

Microservices Versus Monoliths

Today, there are two often-discussed approaches to building applications. Applications can either be monolithic or they can be built using microservices. Both approaches exist on either end of a spectrum on which most software projects fall somewhere in between. Very few applications are completely monolithic or perfect microservices.

Monolithic applications are built such that all of the components ...