The System Design Interview Cheatsheet

Career 👁️ 2 views Last updated Apr 26, 2026

The Anatomy of a System Design Interview

You walk into the room and the interviewer says: "Design Twitter." You have 45 minutes. Panicking is not an option. The goal of this interview is not to build a working system, but to demonstrate how you handle trade-offs, scaling, and ambiguity.

Always follow the RADIO framework: Requirements, Architecture, Data Models, Interface (API), and Optimization.

1. Requirements Gathering (5 mins)

Never start drawing immediately. Clarify the scope. Are we designing for 100 users or 100 million? Is the system read-heavy (like Twitter) or write-heavy (like a logging system)? Define the exact features in scope. (e.g., "We will focus on posting a tweet and viewing the timeline, but ignore direct messaging for now.")

2. High-Level Architecture (10 mins)

Draw the boxes. You need a Client (Mobile/Web), a Load Balancer, Web Servers, an Application layer, and a Database. Keep it simple and monolithic at first, then discuss how you would split it into microservices later.

3. The Database Choice

This is where candidates fail. You must justify your database choice.

Relational (SQL / PostgreSQL): Use when data integrity is paramount (financial transactions) and data is highly structured with clear relationships. (ACID compliance).
NoSQL (MongoDB / Cassandra): Use when you need massive horizontal scalability, flexible schemas, or are dealing with an enormous volume of simple reads/writes (like a Twitter timeline).

4. Scaling & Optimization (20 mins)

The system works for 1,000 users. How do we survive 10 million? Introduce the holy trinity of scaling:

Caching: Put Redis or Memcached in front of the database to serve frequently accessed data (like viral tweets) instantly.
CDN (Content Delivery Network): Serve images and static assets from servers physically closer to the users via Cloudflare or AWS CloudFront.
Message Queues (Kafka / RabbitMQ): Decouple heavy background tasks (like sending push notifications or generating analytics) from the main user-facing web servers.

Remember: There are no perfect designs, only trade-offs. Always explain why you made a specific choice.