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

# What are we learning in this course?

This course is useful for you if

1. You are building a scalable web application - whether at a startup or a large company
2. You are preparing for System Design Interviews

My goal in this course is to help you understand the following three things:

1. Fundamental concepts and terminology related to Distributed Systems, e.g., CAP theorem, Hashing, Sharding, Consistency, etc.
2. What are the key factors to consider while designing a distributed/scalable system?
2. How to evaluate different solutions/approaches to scale based on the requirements of your application.

We will be focusing on the practical aspects of creating and maintaining scalable systems. If you have used or plan to use a cloud service like AWS, Azure, etc., get ready to look under the hood. Even though we are taking a practitioners approach, we will still spend a considerable amount of time on the theoretical distributed system concepts that are required. Of course, we will skip the extremely theoretical concepts like failure modes and Amdhal's laws.

# Case Study: Filtragram
As a case study, we are going to build a web-scale application called **Filtragram**. The name might sound familiar as our app allows users to upload pictures after applying filters to their Photos. We are going to assume that we have a kickass mobile application and we are only going to focus on the web application that would need to scale as users and their activity increases. As we learn new concepts, we will incorporate the learnings in our Filtragram web application. This bottom-up approach is helpful in understanding how different techniques apply to varying stages of the product while the product evolves from your five friends to hundreds of millions of users.

# It's a game of compromises: We'll learn about tradeoffs: 

>No distributed system is perfect. 

Designing a scalable system is all about trade-offs. These trade-offs change with the unique requirements of your application, and that's why every system ends up being slightly different. While designing, you identify the most critical aspects of your application and then develop the system to ensure that the essential operations are optimized. However, it's a zero-sum game, and when you tune for one action, your design makes some of the other activities slow.

When you are building a scalable application, you would have to inevitably start using many different subsystems that will have a variety of unique characteristics of their own. A significant factor in your choice of subsystems would be based on:
1. What are the optimizations that you’re looking to achieve?
2. What are the compromises that you’re willing to make?

As an example, Google's DataStore does not allow more than one update to an entity per second. So if you were designing a system that needs more than one update to an entity per second you won’t be able to use the Google data store. 

Similarly, if you are implementing change password feature, it wouldn’t be wise to use an eventually consistent database (we will cover eventual consistency later). If you use an eventually-consistent database, imagine the user's horror if they can log in using their old password after they have updated to the new password.

# How is this course helpful in System Design Interviews?
>In a System Design Interview, there are usually no 'right' answers. 

Your interviewer is evaluating you on your ability, knowledge, and understanding to compare different approaches and hash out the pros and cons of each method. As the discussion progresses and the design evolves, you are expected to refine your strategy based on the scenarios thrown your way. 

Here are a couple of examples of evolving scenarios

1. At the beginning of the interview, you might have assumed that the application is read-heavy. Now, your interviewer can throw a curveball by changing the requirements and making the service right-heavy.
2. You might have been optimizing the app for **low-latency** and **high-throughput**. What would you do differently when the interviewer wants high-throughput and doesn't care about latency?

Now, at this point, if you are saying that I don't know what **latency vs. throughput** puzzle is, don't worry. We are going to cover this and much more in this course.

Once you've understood the basics, you should look at [Grokking the System Design Interviews](https://www.educative.io/collection/5668639101419520/5649050225344512) course. 

# How is this course helpful in your career?

If you are a software engineer/architect building a web-scale application, you are most likely using cloud provides like AWS, Azure, Google Cloud, etc. 

Let's look at data storage. AWS offers a plethora of services for storing data e.g.

- Simple Storage Service (S3)
- DynamoDB
- RDS
- Redshift
- Kinesis etc. 

**[[TODO: insert a picture of logos of these services]]**

Each one of these services is optimized for specific use cases. More importantly, as you might have guessed already, they are not performant if not used for the appropriate use case. 

And this is just storage. You have to make similar choices for other aspects for your application e.g.

- **Compute**: What kind of compute instances you need - do you want EC2 instances or you wish to use Lambda functions.
- **Containers**: Do you need them? Is Kubernetes the right way to go?
- **Caching**: Is Redis better? Maybe Memcache is?

and the list continues.

It sounds like a lot to learn. But there is an easy way. Learn the basics of distributed systems so that you can evaluate each offering based on the characteristics like

- Queries per second (QPS) or Transactions per second (TPS)
- Throughput vs. Latency
- Strong or Eventually consistent
- Read-optimized vs. Write-Optimized

I aim to unpack the basics of distributed systems to you in a way that you can not only design cloud services but also evaluate existing cloud services to use as the foundation for your next web-scale application.

Let's get started

**[[TODO: Insert some welcoming image here]]**



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

System Design Interviews or not: Why take this course?

What are we learning in this course?

Case Study: Filtragram