The Ultimate System Design Cheat Sheet

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.

Reliability & Resilience

• Leader Election: Mechanism in distributed systems to designate a single node as the coordinator or primary (leader) among peers. This ensures one authoritative source (e.g., choosing a master database or cluster leader) to avoid conflicts and maintain consistency.

• Circuit Breaker: A pattern that “fails fast” by detecting when a service call is repeatedly failing and then breaking the call circuit. Further requests to the failing component are halted for a short time, preventing cascading failures and allowing the system to recover gracefully.

• Health Checks: Regular probes or heartbeats to verify that services or nodes are up and responsive. Health checks (e.g., HTTP heartbeat endpoints or ping messages) let load balancers and orchestrators route traffic only to healthy instances and restart or failover unhealthy ones.

• Failover: Automatic switching to a redundant or standby component upon failure of the primary. For example, if a primary server or database goes down, a backup takes over seamlessly so the system can continue operating with minimal disruption.

• Disaster Recovery: Strategies to restore systems and data after catastrophic failures (data center outage, major bugs, etc.). This includes off-site backups, multi-region failover, and recovery plans to minimize downtime and data loss in worst-case scenarios.

Advanced Architecture Patterns

• CQRS (Command Query Responsibility Segregation): Splits read and write operations into separate models or services. By segregating the write side (commands) from the read side (queries), each can scale and be optimized independently. Useful when read-heavy versus write-heavy workloads have different performance, scaling, or data structuring needs.

• Event-Driven Architecture: An architectural style where events (state changes or messages) trigger reactions throughout the system. Components communicate via event streams, message queues, or a pub/sub model rather than direct calls. This decouples services and enables scalable, asynchronous processing (ideal for real-time updates, integrations, and handling spikes by smoothing workloads).

• Saga Pattern: A pattern for maintaining data consistency across multiple services without a single ACID transaction. A saga breaks a distributed transaction into a series of local steps (each service performs its action) with compensating actions to undo steps if something fails. Useful in microservices for long-lived transactions – ensures all services eventually reach a consistent outcome (either all steps complete or all rolled back) without locking everything at once.

• Event Sourcing: An approach to storage where changes in state are logged as a sequence of immutable events, rather than overwriting the latest state. The system’s state is derived by replaying these events. Event sourcing provides a reliable audit trail and enables rebuilding state or debugging by looking at the full history. Often paired with CQRS (events represent “writes,” and a separate read model derives current state) and used when you need undo/redo functionality or auditability of every change.

Communication & API Design

• gRPC: A high-performance, open-source RPC framework from Google that uses HTTP/2 under the hood and Protocol Buffers for compact binary messaging. gRPC enables efficient, strongly-typed client-server communication with support for bi-directional streaming. It’s great for low-latency microservice communication or between backend services, but requires support for protobuf and isn’t human-readable like REST/JSON.

• WebSockets: A full-duplex communication protocol over a single TCP connection, allowing servers and clients to send data to each other in real-time. WebSockets are ideal for persistent, bi-directional communication (e.g., chat apps, live notifications, multiplayer games) where long-lived connections push updates instantly, unlike HTTP request/response which is one-way and short-lived.

• GraphQL vs REST: GraphQL is a query language for APIs that lets clients request exactly the data they need in a single request (via a single endpoint), whereas REST provides fixed data resources at multiple endpoints (often returning more data than needed). GraphQL offers flexibility and reduces over-fetching/under-fetching, while REST is simpler, cache-friendly, and stateless. Choosing between them depends on use case (GraphQL for complex data fetching needs, REST for simplicity and broad client support) – see our in-depth REST vs GraphQL vs gRPC comparison for more details.

• API Versioning: A practice to evolve APIs without breaking existing clients. Common strategies include versioned URLs (e.g., /api/v2/...) or version headers. Versioning allows introducing new features or changes (v2, v3…) while keeping older versions stable for clients that haven’t migrated, ensuring backward compatibility in a long-lived API.

• Rate Limiting: Controlling how often clients can call an API (e.g., 100 requests per minute). Rate limiting protects services from abuse or overload by capping usage. It ensures fair resource use and maintains quality of service – excess requests may be throttled or rejected (often accompanied by HTTP 429 Too Many Requests responses).

• OAuth/JWT: OAuth is an authorization framework that lets users grant third-party apps access to their data without sharing passwords (commonly used for “Login with X” flows). JSON Web Tokens (JWT) are a compact token format (JSON payload signed) often used in auth systems to prove identity or claims. Together, OAuth provides the handshake (obtaining tokens securely), and JWTs serve as the access/ID tokens the client sends with API calls. This approach is fundamental for securing APIs, as it ensures only authenticated and authorized requests are processed (statelessly, via tokens).

• Idempotency: An important property for API endpoints (especially in payments or retry logic) where repeating the same request multiple times has the same effect as doing it once. For example, an idempotent operation like a GET or a properly-designed PUT can be safely retried – if a network call fails, the client can resend without risk of duplicate side effects. Idempotency is crucial for reliability so that clients can recover from failures (like timeouts) without inconsistent results.

Data Modeling & Indexing

• Indexing: Creating auxiliary data structures (like B-trees or hash tables) on specific database columns/fields to speed up query lookups. Indexes drastically improve read performance by allowing the database to find data without scanning full tables, at the cost of extra storage and slower writes (since indexes need updating). Choosing the right fields to index (e.g., primary keys, frequently queried columns) is key to database optimization.

• SQL vs NoSQL: Choosing between relational (SQL) and non-relational (NoSQL) databases depends on data and scale needs. SQL databases (MySQL, PostgreSQL) enforce structured schemas and ACID transactions – great for complex relationships and multi-row transactions. NoSQL databases (MongoDB, Cassandra, etc.) offer flexible schemas or key-value storage and scale horizontally with ease, often at the cost of strict consistency or complex queries. Understanding the trade-offs (structure vs flexibility, vertical vs horizontal scaling) is crucial – use the database type that fits your data model and access patterns.

• Data Modeling: Designing how data is structured and related. Good data modeling involves mapping the entities, their attributes, and relationships based on how the application will use the data. Consider normalization vs denormalization: normalized (structured to reduce redundancy) for integrity in SQL, vs denormalized (duplicated or embedded data) for fast reads in NoSQL. Also consider how the data will grow and be queried (e.g., one-to-many relationships, access patterns) – a well-thought-out schema prevents scalability and consistency headaches down the line.

• Database Sharding: Splitting a large database into smaller pieces (shards) that are spread across multiple servers. Each shard holds a subset of the data (for instance, users A-M on shard 1 and N-Z on shard 2, or based on a hash of userID). Sharding allows horizontal scaling beyond a single node’s capacity, so you can handle very large datasets or traffic by distributing load. It introduces complexity (you need a shard key and possibly a lookup service, and cross-shard queries are hard), but it’s a go-to strategy when a single database can’t handle the read/write volume.

Monitoring & Observability

• Logging: Recording events, transactions, and errors from your application. Logs (app logs, access logs, error logs) are like a system’s diary – they help engineers debug issues and trace what happened. Good practice is to centralize logs (using tools like ELK stack or cloud logging services) and include context (timestamps, request IDs) so that troubleshooting in a distributed system is easier.

• Monitoring: Continuously measuring system metrics and health in real time. This typically involves dashboards and agents that track KPIs like CPU/memory usage, request rates, error rates, latency, database throughput, etc. Monitoring systems (e.g., Prometheus, CloudWatch) collect these metrics and often visualize them, allowing teams to spot anomalies or trends (like traffic spikes or memory leaks) early.

• Alerts: Automated notifications triggered when certain metrics or health checks breach defined thresholds. For example, send an alert (email, Slack, pager) if 5% of requests are failing or if CPU stays above 90% for 5 minutes. Alerts ensure that engineers are promptly aware of issues in production – a critical part of SRE/DevOps practices so that problems in the system get human attention before they escalate.

• Observability: A holistic approach that combines logging, monitoring metrics, and distributed tracing to give a deep insight into system behavior. Observability means designing your system such that you can ask why something is happening just by examining external outputs (logs/metrics/traces). It’s the evolution of mere monitoring – focusing on being able to debug complex, emergent issues in distributed systems. High observability is achieved by instrumenting code (emitting structured logs, metrics, traces) so that when things go wrong in production, you can pinpoint the cause (e.g., which service or which part of the request flow) quickly. In essence: monitoring tells you something’s wrong, observability helps you figure out what and why.

Capacity Estimation

• Estimating QPS: Determine queries per second (or requests per second) by analyzing the expected number of users and their actions. For example, if you have 1 million daily active users and each makes on average 1 request per second at peak, that’s ~1M QPS to design for. In interviews, doing back-of-the-envelope calculations for QPS helps justify decisions (like how many servers or threads you might need, load balancing strategies, etc.). Always consider read vs write QPS, and peak vs average traffic – design for peak load to ensure the system can handle bursts.

• Estimating Storage: Roughly calculate how much data the system will store and generate over time. This includes database storage, media files, logs, etc. For instance: if each user generates 100KB of data per day, and you have 1 million users, that’s ~100 GB per day, which over a year is ~36 TB (100GB * 365). Such estimates guide choices like database type (and sharding or partitioning needs), how often to archive or delete data, and what it might cost in cloud storage. Being able to estimate storage needs in interviews shows you’re considering data growth and capacity planning (e.g., “we’ll need about 50 GB of storage per month for images, so a single database node might suffice initially, but we should plan for sharding or using S3 as we scale”).

• Why it Matters: Capacity estimation is often a cornerstone in system design interviews. Interviewers expect candidates to sanity-check their design against scale requirements. By quantifying QPS, storage, or bandwidth needs, you demonstrate that your architecture can handle the expected load. It prevents designing a system that unknowingly can’t meet the demand, and it gives you a basis for discussing scaling strategies (like “with ~10 QPS initially we can use one server, but if we grow to 10k QPS we’d deploy a load balancer and multiple instances…”). In short, doing the math for capacity shows foresight and practical understanding of how theoretical designs run on real infrastructure.

Common System Design Questions

• Design Twitter

• Design Instagram

• Design Ticketmaster

• Design Dropbox or Google Drive

• Designing Yelp or Nearby Friends

• Design a search autocomplete service

• Design a streaming service (e.g., Netflix)

• Design a social network (e.g., Facebook)

• Design a URL shortening service (e.g., bit.ly)

• Design a distributed cache (e.g., Memcached)

• Design a messaging service (e.g., WhatsApp, Messenger)

Check out common system design interview questions in detail.

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:

• SQL vs. NoSQL
• Latency vs Throughput
• Strong vs Eventual Consistency
• Proxy vs. Reverse Proxy
• Serverless architectures vs. traditional server-based

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.

Learn about the 10 system design challenges for 2025.

Common Pitfalls in System Design Interviews

• Skipping Requirements: Jumping straight into drawing the system without first clarifying the requirements and constraints. This often leads to designs that miss key features or misjudge scale. Avoid by asking questions at the start – nail down what you’re solving and the expectations (functional and non-functional) before you design.

• Not Discussing Trade-offs: Every design decision has pros and cons (SQL vs NoSQL, consistency vs availability, etc.), but some candidates present one solution as if it’s the only way. Failing to acknowledge alternatives or downsides is a red flag. Always mention trade-offs and why you chose one approach over another – it shows a balanced understanding.

• Ignoring NFRs (Non-Functional Requirements): Many forget critical aspects like security, reliability, scalability, and monitoring. A design might meet the basic feature requirements but fall over in real-world conditions. Don’t forget to address things like performance, data replication, failover strategy, rate limiting, and how you’ll monitor the system – interviewers listen for these.

• Overengineering: Introducing overly complex components or premature optimizations. For example, adding unnecessary microservices, multiple databases, or elaborate caching layers for a simple problem can hurt more than help. Keep it as simple as possible to meet the requirements. Show that you can scope your solution appropriately given the scale – you can always mention how it could evolve if the product grows (instead of starting with a NASA-level architecture for a small app).

• Poor Time Management: Spending too much time on one aspect (like an extended discussion on a minor component or obsessing over exact API syntax) and then rushing or skipping other key parts. This imbalance can leave important sections of the design unexplored. Practice a structured approach: high-level design first, then drill into a few critical areas. Keep an eye on the clock and ensure you cover core components (data storage, computation, communications, etc.) sufficiently.

• Lack of Clarity in Communication: Even a great design can fall flat if the interviewer can’t follow your thought process. Common mistakes include disorganized explanations, not articulating reasoning, or using too much jargon without explanation. Remember to think aloud and use clear, concise language. Guiding the interviewer through your mental model – using analogies or simple terms for complex ideas – can make a big difference. It’s not just what you design, but how you convey it.

• One-Size-Fits-All Solutions: Some candidates try to force a memorized template (“just use Kafka for everything” or “always start with 3 tiers and add caching and async queue”) without tailoring to the question. This comes off as rote and may not address the problem’s unique challenges. Avoid cookie-cutter architectures – instead, adapt your toolkit of common components to the specific scenario given. Interviewers appreciate when you justify choices in the context of the problem (not just because “it’s what X company does”).

Each of these pitfalls is avoidable. By being mindful of them, you can present a well-rounded system design that is thoughtful, relevant, and demonstrates your expertise – setting you apart in the interview.