Arslan Ahmad

December 30th, 2024

The Ultimate System Design Cheat Sheet

Mastering System Design: The Ultimate Quick-Reference Guide

Welcome to the "System Design Cheat Sheet" – a quick, go-to reference designed to aid both beginners and experienced engineers in preparing for system design interviews. This guide simplifies the essential components of system design, helping you understand and recall important concepts, methodologies, and principles. Whether you're stepping into your first tech interview or you're a seasoned professional aiming to brush up your knowledge, this cheat sheet will help you navigate the broad landscape of system design with confidence.

System Design Basics

Definition: System design is the process of designing the architecture, components, and interfaces for a system to meet specific needs.
Importance: Improves system performance, scalability, reliability, and security.
Components: Client, Server, Database, etc.

System Design Diagram

Fundamental Concepts

Vertical Scaling: Increasing the resources of a single node.
Horizontal Scaling: Increasing the number of nodes.
Availability: The ability of a system to respond to requests in a timely manner.
Consistency: The degree to which all nodes in a distributed system see the same data at the same time.
Partition Tolerance: The ability of a system to continue functioning when network partitions occur.
CAP Theorem: Based on Consistency, Availability, Partition Tolerance - pick two out of three.
ACID: Atomicity, Consistency, Isolation, Durability - properties of reliable transactions.
BASE: Basically Available, Soft state, Eventual consistency - an alternative to ACID.
Load Balancer: A load balancer is a technology that distributes network or application traffic across multiple servers to optimize system performance, reliability, and capacity.
Rate Limiting: Control of the frequency of actions in a system, often to manage capacity or maintain quality of service.
Idempotence: Property of certain operations in mathematics and computer science, where the operation can be applied multiple times without changing the result beyond the initial application.

CAP Theorem

Data

Data Partitioning: Dividing data into smaller subsets.
Data Replication: Creating copies of data for redundancy and faster access.
Database Sharding: Splitting and storing data across multiple machines.
Consistent Hashing: Technique to distribute data across multiple nodes.
Block Service: A block service is a type of data storage used in cloud environments that allows data to be stored in fixed-sized blocks.

Storage Systems

SQL: Relational database, structured data.
NoSQL: Non-relational database, flexible schemas, scaling out.
Distributed key-value stores: Stores data as key-value pairs and is designed for horizontal scalability.
Document databases: Document databases store data as semi-structured documents, such as JSON or XML, and are optimized for storing and querying large amounts of data.
Database Normalization: Process used to organize a database into tables and columns to reduce data redundancy and improve data integrity.
Caching: Storing copies of frequently accessed data for quick access.
Content Delivery Network (CDN): Distributed network of servers providing fast delivery of web content.
Eventual Consistency: A consistency model which allows for some lag in data update recognition, stating that if no new updates are made, eventually all accesses will return the last updated value.

Distributed Systems

Distributed Systems: Systems where components are located on networked computers.
Load Balancing: Distributing network traffic across multiple servers.
Heartbeats: Signals sent between components to indicate functionality.
Quorums: Minimum number of nodes for decision making.
Fault Tolerance: Ability of a system to continue operating properly in the event of the failure of some of its components.
Redundancy: Duplication of critical components of a system with the intention of increasing reliability.

Networking and Communication

REST: Architectural style for networked applications, uses HTTP methods.
RPC: Communication method where a program causes a procedure to execute in another address space.
Sync vs Async: Synchronous waits for tasks to complete, asynchronous continues with other tasks.
Message Queues, Pub-Sub Model, Streaming: Techniques for communication between systems.

Architectural Styles

Monolithic: Single-tiered software where components are interconnected.
Microservices: Software is composed of small independent services.
Serverless: Applications where server management is done by cloud provider.

Security and Compliance

Security: Protecting data and systems from threats.
Authentication: Verifying the user's identity.
Authorization: Verifying what a user has access to.

Performance

Latency: Time taken to respond to a request.
Throughput: Number of tasks processed in a given amount of time.
Performance vs Scalability: Performance is about speed; scalability is about capacity.
Response Time: Response time is the total time taken for a system to process a request, including the time spent waiting in queues and the actual processing time.

Design Patterns and Principles

Design Patterns: Reusable solution to common problems.
SOLID: Five principles for object-oriented design.
- Single Responsibility Principle (SRP): A class should have one, and only one, reason to change. This means a class should only have one job or responsibility.
- Open-Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, you should be able to add new functionality without changing the existing code.
- Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types, meaning that if a program is using a base class, it should be able to use any of its subclasses without the program knowing it.
- Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This means that a class should not have to implement interfaces it doesn't use.
- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. In addition, abstractions should not depend on details. Details should depend on abstractions. This principle allows for decoupling.
Twelve-Factor App: Methodology for building software-as-a-service apps.

Common System Design Questions

System Design Interview Tips

System design interviews can be challenging because they require a blend of technical knowledge, problem-solving skills, and clear communication. Here are some high-level tips to keep in mind:

1. Clarify the Requirements

Before you jump into the architecture, ask clarifying questions. What are the scale requirements (number of users, requests per second)? Are there any special constraints (data security, latency SLAs)? Understanding these will help you design a more relevant solution.

2. Think Aloud

Interviewers want to see your thought process. Explain your reasoning, trade-offs, and why you’re taking certain steps. Even if you make a mistake, showing how you arrive at decisions can demonstrate problem-solving skills.

3. Start Broad, Then Dive Deep

Begin by outlining the high-level architecture (components, data flow, major technologies) and then zoom into specific areas (database schema, caching strategies, load balancer configurations) as time permits or as prompted by the interviewer.

4. Balance Trade-Offs

System design is often about trade-offs: cost vs. performance, complexity vs. scalability, consistency vs. availability, etc.

Demonstrate awareness of these by articulating them clearly during your discussions.

Here are some important system design trade-offs:

5. Use Diagrams

Whenever possible, sketch a quick diagram (even a rough one) to visualize your solution. This helps the interviewer follow your thought process more easily and offers a reference point for discussion.

6. Address Common Concerns

Make sure you touch on security, reliability, and monitoring.

While details can be specific to the problem, acknowledging these essentials shows you’re thinking holistically.

7. Time Management

Be mindful of time constraints. Allocate enough time to cover the main components of your design without getting lost in micro-optimizations.

8. Iterate and Evolve Your Design

After outlining a base solution, discuss potential improvements, optimizations, and how you could scale or evolve the system over time.

How to Answer a System Design Interview Question

When faced with a system design question (e.g., “Design Instagram,” “Build a URL shortener”), you can follow a structured approach:

1. Restate the Problem

Confirm you understand what is being asked. Summarize the requirements in your own words, making sure you capture key features (e.g., user authentication, image uploads, feed algorithms).

2. Gather Requirements and Constraints

Ask questions to clarify functional (e.g., “Do we need user profiles with follower/following functionality?”) and non-functional requirements (e.g., “What is the target user base? What are our latency expectations?”).

Identify constraints such as storage limits, maximum throughput, or compliance requirements.

3. Propose a High-Level Architecture

Sketch the main components: front-end clients, application servers, databases, caching layers, load balancers, etc.

Briefly explain how data flows among these components.

4. Discuss Key Design Decisions

Data Storage: SQL vs. NoSQL, caching strategies. Scalability: Horizontal vs. vertical scaling, sharding, replication. Performance Optimizations: Caching, load balancing, content delivery networks. Reliability: Redundancy, failover strategies, disaster recovery. Security: Encryption, authentication, role-based access control.

5. Dive Into Specifics

Depending on the scenario, zoom in on critical parts: How do you handle large file uploads? How do you ensure real-time notifications? How do you deal with read/write spikes?

6. Address Trade-Offs

For each choice (e.g., SQL vs. NoSQL), briefly mention why you chose it and what you might lose as a result. It’s okay to make assumptions as long as you explain your reasoning.

7. Anticipate Bottlenecks & Future Growth

Point out possible bottlenecks (e.g., a single database node) and how you’d mitigate them (e.g., replication, partitioning).

Suggest how the system could evolve to handle 10x or 100x traffic in the future.

8. Summarize and Check for Gaps

End by recapping your solution, revisiting the requirements to confirm you’ve covered all necessary points.

Learn more details on how to approach system design interview question.

How to Understand the Requirements

When tackling a system design question—be it in an interview or a real-world project—the very first step is to deeply understand what’s being asked. This might seem straightforward, but overlooking certain requirements can lead to designing an underperforming or incomplete system. Properly gathering requirements lays a solid foundation for every architectural decision that follows.

Here’s how to break it down:

1. Functional Requirements

a. Identify the Key Features
Functional requirements describe the business logic and core operations your system must support.

For instance, if you’re building an e-commerce platform, core features may include managing products, facilitating user authentication, processing transactions, and generating order histories.

If you’re designing a content distribution platform, essential functions might revolve around uploading, streaming, and categorizing media.

Example: “Users should be able to upload short videos and share them publicly.”

b. Define the Data Flows
Clarify how data enters and moves through the system. Determine what forms of input are possible (e.g., text, images, audio), how it’s processed or transformed, and what outputs need to be produced.

This often includes how users interact with the application interface, how external services send data to your system (like webhooks), and how data is served to clients (APIs, frontend calls, or dashboards).

Example: “Once a user uploads an image, the system should generate multiple thumbnail sizes, store them, and return URLs.”

c. Consider Edge Cases
From the start, think about scenarios that go beyond straightforward use (e.g., user tries to upload extremely large files, or tries to read content that doesn’t exist).

In a system design interview, proactively discussing edge cases shows foresight and attention to detail.

Example: “What happens if the image is corrupted or if the user tries to upload an unsupported format?”

2. Non-Functional Requirements

While functional requirements lay out what the system does, non-functional requirements (NFRs) dictate how well it should do it. They often determine the constraints for performance, scalability, security, and more.

Performance (Latency and Throughput)
- Latency: The time it takes for a single request to travel through the system. Requirements might specify a maximum acceptable response time.
- Throughput: How many requests the system can handle per second (or minute). If you expect high traffic, you’ll need mechanisms—like caching or load balancing—to meet your throughput goals.
- Example: “The service should handle 1,000 requests per second with a 95th percentile response time of under 200ms.”
Scalability
- Scalability addresses how the system can grow (or shrink) to meet demand. Distinguish between vertical scaling (adding more resources to a single server) and horizontal scaling (adding more servers). The type of scaling impacts how you choose databases, load balancers, messaging queues, etc.
- Example: “Our user base may grow from thousands to millions over the next year. We need an architecture that accommodates rapid horizontal scaling.”
Reliability and Fault Tolerance
- Reliability means the system consistently works as intended, even under partial failures. A fault-tolerant system includes redundancies—like replication across multiple servers or data centers—to avoid single points of failure.
- Example: “If any single node fails, traffic should seamlessly reroute to other healthy nodes with minimal disruption.”
Availability
- Availability is often measured as uptime over a given period (e.g., 99.9% monthly availability). Depending on your use case, a brief outage could be disastrous or merely inconvenient.
- Example: “The system must maintain 99.99% uptime due to high financial impact of outages.”
Security
- Security features typically include authentication, authorization, and encryption (in transit and at rest). Compliance may also be relevant if the system deals with sensitive data (e.g., healthcare or financial information), necessitating specific regulations like HIPAA or PCI-DSS.
- Example: “User data must be encrypted at rest, and multi-factor authentication should be enabled for administrative actions.”
Cost Constraints
- Even the most robust architecture must be balanced against financial realities. Cloud resources, data transfers, and premium services add up quickly. Budgetary constraints might limit or dictate certain design choices.
- Example: “We aim to minimize infrastructure costs, so we’ll only consider managed services that can autoscale to meet demand without over-provisioning.”

3. Asking Clarifying Questions

It’s essential to ask clarifying questions to ensure you fully capture the requirements.

In a system design interview, the interviewer often expects you to gather details proactively:

Traffic expectations: “What is the average and peak traffic volume?”
Data growth: “How much data do we anticipate storing weekly, monthly, or yearly?”
Latency targets: “Do we need sub-second responses, or are a few seconds acceptable?”
Critical features vs. nice-to-have: “Are there secondary features we can defer if time is limited?”
Geographical distribution: “Will users be global, or is the service localized to one region?”
SLAs (Service Level Agreements): “What are the uptime or performance guarantees we need to meet?”

By working on these questions early, you establish the design boundaries and can propose trade-offs that address real-world limitations. This approach not only builds trust with the interviewer but also guides your system architecture in the right direction, ensuring you’re solving the correct problem.

“Understanding the Requirements” sounds simple, but it’s arguably the most critical step in any system design process.

Without clear knowledge of both functional and non-functional requirements, your design will be based on assumptions that can quickly derail the rest of the conversation.

Above all, keep communicating: confirming your assumptions and constraints ensures you’re crafting a solution tailored to the real needs of the system and its users.

Conclusion

We hope this "System Design Cheat Sheet" serves as a useful tool in your journey towards acing system design interviews.

Remember, mastering system design requires understanding, practice, and the ability to apply these concepts to real-world problems. This cheat sheet is a stepping stone towards achieving that mastery, providing you with a foundation and a quick way to refresh your memory.

As you go deeper into each topic, you'll discover the intricacies and fascinating challenges of system design. Good luck!