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.

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: 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.

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

• Design a URL shortening service (e.g., bit.ly)
• Design a social network (e.g., Facebook)
• Design a messaging service (e.g., WhatsApp, Messenger)
• Design a distributed cache (e.g., Memcached)
• Design a search autocomplete service
• Design a streaming serice (e.g., Netflix)
• Design Twitter
• Design Dropbox or Google Drive
• Design Instagram
• Designing Yelp or Nearby Friends
• Design Ticketmaster

System Design Interview Tips

• Understanding the problem
• Defining System Interfaces
• Back-of-the-Envelope Estimation
• Discuss trade-offs and constraints
• Trade-offs

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 delve deeper into each topic, you'll discover the intricacies and fascinating challenges of system design. Good luck.

Read more about system design:

• Demystifying System Design Interviews: A Guide