System Design and Scalability Flashcards
Handling the System Design and Scalability Questions
Communicate
Go broad first
Use the whiteboard
Acknowledge interviewer concerns
Be careful about assumptions
State your assumptions explicitly
Estimate when necessary
Drive
Design: Step-by-Step
Step1: Scope the Problem
Step 2: Make Reasonable Assumptions
Step 3: Draw the Major Components
Step 4: Identify the Key Issues
Step 5: Redesign for the Key Issues
Algorithms that Scale: Step-By-Step
Step 1: Ask Questions
Step 2: Make Believe
Step 3: Get Real
Step 4: Solve Problems
Horizontal Scaling
Increase the number of nodes. For example, you might add additional servers, thus decreasing the los on any one server.
Vertical Scaling
Increase the resources of a specific node. For example, you might add additional memory to a server to improve its ability to handle laid changes. Typically easier then horizontal scaling, but it’s limited. You can only add so much memory or disk space.
Load Balancer
Distributes a system’s load evenly so that one server doesn’t crash and take down the whole system. You have to build out a network of cloned servers that all have essentially the same code and access to the same data.
Database Denormalization
Adding redundant information into a database to speed up reads. Joins in a relational database such as SQL can get very slow as the system grows bigger. For this reason, you would generally avoid them. Denormalization is one part of this.
NoSQL
A database that does not support joins and might structure data in a different way. It is designed to scale better.
Database Partitioning (Sharding)
Split the data across multiple Mach ones while ensuring you have a way of figuring out which data is on which machine.
Vertical Partitioning
Partitioning by feature. One drawback of this is that if one of these tables gets very large, you may need to repartition that database (possibly using a different partitioning scheme).
Key-Based (or Hash-Based) Partitioning
Uses part of the data (for example, and ID) to partition it. A very simple way to do this is to allocate N servers and put the data on mod(key,n). One issue with this is that the number of servers you have is effectively fixed. Adding additional servers means reallocating all the data - a very expensive task.`
Directory-Based Partitioning
Maintain a lookup table for where the data can be found. This makes it relatively easy to add additional servers, but it comes with two major drawbacks. First, the lookup table can be a single point of failure. Second, constantly accessing this table impacts performance.
Caching
A simple key-value pairing and typically sits between your application layer and your data store. The cache is tried first before data is looked up in the data store. You may cache a query and its results directly. Or, alternatively, you can cache the specific object.
Asynchronous Processing & Queues
Pre-process example: A queue of jobs to be done that updates website. The queue may be slightly out of date. However, we won’t force the user to wait. If the user must wait, we notify the user and allow the process to run asynchronously w.r.t. to the website/app.
Bandwidth
The maximum amount of data that can be transferred in a unit of time (bits/second). Maximum number of items that roll off the conveyor belt per second. Increase with fatter or faster belt.
