Cover the basics and learn how to design and develop distributed systems.

Become a Distributed Systems Professional

Gone are the days when monolithic applications were the norm. Most applications we use today are too complex for that type of construction. Instead, most applications that appear as a single unit are actually built as a collection of inter-operating but independent computational components. Developers are expected to have mastery over a programming language or two. Moreover, they should also know the basics of distributed systems.

In this module, we’ll learn what distributed systems are, and learn about the challenges unique to distributed systems. We’ll cover popular architectural patterns for achieving targets like replication and sharding. We’ll complete the module with a study of two popular distributed systems: Apache Spark and Apache Druid. With the knowledge gained through this module, we’ll be able to design and develop distributed systems. We’ll also develop an understanding of optimal design and architectural choices based on the application requirements.

Introduction to Distributed Systems for Dummies

As discussed earlier, a reliable system ensures the correctness of the system itself. But what property of a distributed system ensures that the system is functional?


This is where availability comes to the rescue.

# What is availability?

Availability is a property of a distributed system that ensures that the system is ready to serve users whenever users need it.

In practice, it's easier to define 
availability in a mathematical formula.

Say, the backend system of the My Cool App was up for $U$ time and down for $D$ time since its launch. Then availability $A$ is defined as
> $A = \frac{U}{U + D}$

So basically, availability is the percentage of time a system was up for a given time range. For example, a system that is $99\%$ available for a year means it will be down for 3.65 days over the period.

>For many systems, around 4 days of downtime over a year is bad.

Note that when we define availability, correctness is implicitly assumed. If the system was up all the time but the data was lost or corrupted, then that does not really mean the system was serving the users as expected, does it?

# Motivation behind available systems

The motivation behind availability is natural. As an example, think of e-commerce platforms like Amazon.

Regardless of the time of the day, e-commerce sites would like to sell products on their platform. People are ordering on these platforms all the time. Being down for a minute means monetary loss for these companies. Nobody wants that.

And it’s not just e-commerce. There are all kinds of websites and applications that target availability as much as possible. Think of Educative. How would you feel if you had the sudden midnight urge to learn about distributed systems and Educative was down?

Any website or app should have the general requirement of being up when users try to use it.

# The availability chart

Let's look at the chart of availability.

| Availability Level    | Allowed Downtime |
| ----------- | ----------- |
| 90%     | 36.5 days       |
| 95%   | 18.25 days        |
| 99% | 3.65 days|
|99.5% | 1.83 days|
|99.9% | 8.76 hours|
|99.95% | 4.38 hours|
|99.99% | 52.6 minutes|
|99.999% | 5.26 minutes|

The chart above shows the relationship between availability percentage vs allowed downtime. When you say your system is $99.999\%$ available, it means over a time span of one year, the system can be down as much as $5.26$ minutes. This means around $30$ seconds every month.

It's a common practice to denote the availability by the number of nines. For example, if we say that the availability of a system is 4-nines, it denotes $99.99\%$ availability. Similarly, 
$99.5\%$ availability is referred to as 2-and-a-half nines.

# Key takeaways

- An available system can serve users when they need it. Many distributed systems tend to be highly available.
- Availability is measurable. We should leverage well-defined metrics to measure the availability of a system and act upon it accordingly.

Learn about the concept of availability in distributed systems.