A practitioner's guide to building scalable systems

Building Scalable Systems: Distributed Systems basics to System Design Interviews

We want to give you the tools to compare multiple approaches and pick the one that works for your scenario.

Grokking the Distributed and Scalable Systems

_In USA, DMV stands for Department of Motor Vehicles. It administers Vehicle Registration and Driver Licensing._

# Humble Beginnings
In a hypothetical town named ScaleVille, that has a population of 300 people; a new DMV Office opens up. As it doesn't expect a lot of people every day, it just has one terminal. Behind the terminal, there's a file cabinet with records for all the vehicles and drivers in the town.

Customers stand in a queue waiting for their turn and once it's their turn, they walk to the terminal and the officer can help them. If the officer needs to refer the records, they step to the file cabinet and retrieves the relevant documents.

The average wait time is a few minutes, and even during peak hours, customers don't spend more than 10 minutes waiting.

# Town's population increases
A year later, a big corporation opens a data center nearby and employs 1000 people. Suddenly, the town has now thousands of residents (those employees have families too).

DMV has become a busy place. Customers have to stand in the queue for 30+ minutes on average and the wait time can be more than an hour during peak hours. The file cabinet also has many many more files, but it's still one file cabinet.

# Multiple terminals
Eventually, it becomes impossible to serve all the customers through the single terminal, and DMV invests and creates five more terminals. Now customers stand in a single queue and the customer at the front of the line goes to the terminal that becomes available. The wait times are now back to a few minutes on average and even peak hours are not that bad. More importantly, DMV has found an effective way to scale if there is more demand. They can easily add more terminals.

Remember, the documents are still stored in a single file cabinet, and every officer walks to the same file cabinet to retrieve records. 

<div style="background-color:#FFFFA5;padding: 10px; padding-left:30px; font-style: italic;">

__By the way:__

The file cabinet will eventually become too full, and the distance between the terminal and the single file cabinet can subsequently become a bottleneck, but we'll leave that part for the time when we are looking at Data Sharding (in a few short chapters).

</div>



# Most Web Scale applications have humble beginnings
Just like our DMV office, Many of the web applications that you would create might never require the scale, complexity, and hassle of using a distributed system. But when you do, you need to understand how to scale your services effectively. This is the beginning of our journey into the world of scaling our applications. Let's go.

_In USA, DMV stands for Department of Motor Vehicles. It administers Vehicle Registration and Driver Licensing._

# Humble Beginnings
In a hypothetical town named ScaleVille, that has a population of 300 people; a new DMV Office opens up. As it doesn't expect a lot of people every day, it just has one terminal. Behind the terminal, there's a file cabinet with records for all the vehicles and drivers in the town.

Customers stand in a queue waiting for their turn and once it's their turn, they walk to the terminal and the officer can help them. If the officer needs to refer the records, they step to the file cabinet and retrieves the relevant documents.

The average wait time is a few minutes, and even during peak hours, customers don't spend more than 10 minutes waiting.

# Town's population increases
A year later, a big corporation opens a data center nearby and employs 1000 people. Suddenly, the town has now thousands of residents (those employees have families too).

DMV has become a busy place. Customers have to stand in the queue for 30+ minutes on average and the wait time can be more than an hour during peak hours. The file cabinet also has many many more files, but it's still one file cabinet.

# Multiple terminals
Eventually, it becomes impossible to serve all the customers through the single terminal, and DMV invests and creates five more terminals. Now customers stand in a single queue and the customer at the front of the line goes to the terminal that becomes available. The wait times are now back to a few minutes on average and even peak hours are not that bad. More importantly, DMV has found an effective way to scale if there is more demand. They can easily add more terminals.

Remember, the documents are still stored in a single file cabinet, and every officer walks to the same file cabinet to retrieve records. 

<div>

__By the way:__

The file cabinet will eventually become too full, and the distance between the terminal and the single file cabinet can subsequently become a bottleneck, but we'll leave that part for the time when we are looking at Data Sharding (in a few short chapters).

</div>



# Most Web Scale applications have humble beginnings
Just like our DMV office, Many of the web applications that you would create might never require the scale, complexity, and hassle of using a distributed system. But when you do, you need to understand how to scale your services effectively. This is the beginning of our journey into the world of scaling our applications. Let's go.

Let's talk about why and how would a DMV office of a small town scale?

What and Why

Node in a Distributed System

Performance and Numbers

Fault Tolerance and Availability

Understanding TIME in Distributed Systems

Data Centers for software engineers

Scaling Distributed Systems

Load Balancers

Structured Storage at Scale

Sharding in Storage Systems

SQL vs NO-SQL

Blob Storage at Scale

Caching in Distributed Systems

Queues and Asynchronous Processing

Data Analytics and Batch Processing

Logging and Monitoring

Searching at Scale

Conclusion

A DMV Office in a Small town

Humble Beginnings