A complete, curated roadmap to master System Design for product-based companies and MNCs (Google, Amazon, Microsoft, TCS, and beyond) — from fundamentals to FAANG-level mock interviews.
- Introduction
- Complete Learning Roadmap
- 🧠 Interview Preparation
- 🛠️ Tools to Practice
- 📺 Best YouTube Channels
- 📖 Recommended Books
- 🚀 30-Day Study Plan
- 💡 Pro Tips
- ✅ Progress Checklist
- 📝 Revision Cheatsheet
System Design is the process of defining the architecture, components, modules, interfaces, and data flow of a software system to satisfy specific requirements — things like scalability, reliability, availability, and performance. Instead of asking "does this code work?", system design asks "will this system survive a million users, a data center outage, or 10x traffic overnight?"
- Product-based companies (Google, Amazon, Microsoft, Meta, Netflix) use system design rounds to evaluate whether you can architect real-world, large-scale systems — not just write correct code.
- Service-based companies (TCS, Infosys, Wipro, Accenture) increasingly include system design in interviews for senior and lead roles, especially for client-facing architecture positions.
- It's the primary differentiator between junior and senior engineering roles — DSA proves you can code; system design proves you can architect.
- It directly reflects real work: on the job, you'll design features, choose databases, and make scaling trade-offs constantly.
- Beginners with 0–2 years of experience preparing for their first system design interview
- Mid-level engineers (2–5 YOE) targeting product-based companies or FAANG-adjacent roles
- Anyone switching from a pure DSA-interview prep track to a well-rounded interview profile
- Engineers who want a structured, no-fluff path instead of randomly watching YouTube videos
| Topic | What to Learn | Best Resource |
|---|---|---|
| Client-Server Architecture | How clients (browsers/apps) communicate with servers, request-response cycle | Gaurav Sen — System Design Playlist |
| HTTP/HTTPS | Request/response structure, methods, status codes, TLS handshake | Hussein Nasser Channel — search "HTTP explained" |
| DNS | How domain names resolve to IP addresses, DNS caching, CDNs and DNS | ByteByteGo Channel — search "How DNS works" |
| Latency vs Throughput | Latency = time per request; throughput = requests handled per unit time; why both matter differently | Gaurav Sen — System Design Playlist |
| CAP Theorem | Consistency, Availability, Partition tolerance — you can only guarantee 2 of 3 during a network partition | Gaurav Sen — System Design Playlist — search "CAP Theorem" |
| Vertical vs Horizontal Scaling | Scaling up (bigger machine) vs scaling out (more machines) — trade-offs and when to use each | ByteByteGo Channel — search "Horizontal vs Vertical Scaling" |
💡 Note on links: Rather than pointing to individual video URLs that can go private/deleted over time, this roadmap links to verified, high-quality channels and playlists — search the suggested keyword within that channel to find the current best video on the topic.
| Topic | What to Learn | Best Resource |
|---|---|---|
| SQL vs NoSQL | Structured/relational vs flexible/document-based; when to use each | Gaurav Sen — System Design Playlist — search "SQL vs NoSQL" |
| Indexing | B-Trees, how indexes speed up reads but slow down writes, composite indexes | Hussein Nasser Channel — search "database indexing" |
| Sharding | Splitting a large database across multiple machines by a shard key | ByteByteGo Channel — search "database sharding" |
| Replication | Master-slave/leader-follower replication, read replicas, replication lag | Gaurav Sen — System Design Playlist — search "database replication" |
| ACID Properties | Atomicity, Consistency, Isolation, Durability — what transactional guarantees actually mean | Hussein Nasser Channel — search "ACID transactions" |
📖 Supplementary articles:
- System Design Primer (GitHub) — the most-starred open-source system design repo; excellent database section
- Martin Kleppmann's blog posts (companion to Designing Data-Intensive Applications, see Books section)
| Topic | What to Learn | Best Resource |
|---|---|---|
| Redis | In-memory key-value store, common data structures, use cases (session store, caching, rate limiting) | Hussein Nasser Channel — search "Redis explained" |
| Cache Invalidation | Write-through, write-back, write-around strategies; the "two hard things in CS" joke exists for a reason | ByteByteGo Channel — search "cache invalidation strategies" |
| CDN Basics | How CDNs cache static content closer to users, edge servers, cache-control headers | ByteByteGo Channel — search "how CDN works" |
| Topic | What to Learn | Best Resource |
|---|---|---|
| Consistent Hashing | How distributed systems assign data to nodes while minimising re-distribution when nodes join/leave | Gaurav Sen — System Design Playlist — search "consistent hashing" |
| Load Balancing | Round-robin, least-connections, IP-hash algorithms; L4 vs L7 load balancers | ByteByteGo Channel — search "load balancing algorithms" |
| Message Queues (Kafka, RabbitMQ) | Async communication, producer-consumer model, at-least-once vs exactly-once delivery | Hussein Nasser Channel — search "Kafka explained" |
| Event-Driven Architecture | Systems reacting to events rather than direct calls; decoupling services via events | ByteByteGo Channel — search "event driven architecture" |
| Topic | What to Learn | Best Resource |
|---|---|---|
| Microservices vs Monolith | Trade-offs: deployment independence vs operational complexity | Gaurav Sen — System Design Playlist — search "microservices vs monolith" |
| API Gateway | Single entry point for routing, auth, rate limiting across microservices | ByteByteGo Channel — search "API Gateway" |
| CQRS | Command Query Responsibility Segregation — separating read and write models | ByteByteGo Channel — search "CQRS pattern" |
| Event Sourcing | Storing state as a sequence of events rather than current-state snapshots | ByteByteGo Channel — search "event sourcing" |
For each problem below: understand the requirements, study the architecture, then practice explaining it out loud — this is what actually builds interview fluency.
Explanation: Takes a long URL and generates a short, unique alias that redirects to the original. Core challenges: generating unique short codes at scale, handling redirect latency, and analytics tracking.
Architecture:
Client → Load Balancer → App Server → Cache (Redis) → Database
│
└─→ Base62 encoder (id → short code)
- Key components: ID generator (counter/Base62 or hash-based), key-value store for URL mapping, cache layer for hot URLs, analytics pipeline
- Scaling considerations: Read-heavy workload (redirects >> creations) → cache aggressively; database sharding by short-code hash
📺 Video: Gaurav Sen — System Design Playlist — search "URL Shortener system design"
Explanation: Real-time bidirectional messaging between users, with delivery guarantees (sent → delivered → read), group chats, and media sharing.
Architecture:
Client A ──WebSocket──► Chat Server ──► Message Queue ──► Chat Server ──WebSocket──► Client B
│
└─→ Message Store (Cassandra/DynamoDB)
└─→ Presence Service (online/offline status)
- Key components: WebSocket connections for real-time delivery, message queue for reliable delivery, persistent message store, presence/online-status service
- Scaling considerations: Sharding by user ID or conversation ID; handling millions of persistent WebSocket connections (connection servers scale horizontally)
📺 Video: Gaurav Sen — System Design Playlist — search "WhatsApp system design"
Explanation: Upload, transcode, store, and stream video content globally with minimal buffering, adaptive quality based on network conditions.
Architecture:
Upload → Transcoding Service (multiple resolutions) → Blob Storage (S3)
│
User Request → CDN (edge cached) ◄───────────────────────────┘
- Key components: Video transcoding pipeline (multiple resolutions/codecs), blob storage for raw + transcoded files, CDN for edge delivery, adaptive bitrate streaming (HLS/DASH)
- Scaling considerations: CDN is the single biggest lever — most requests never hit origin servers; transcoding is async and queue-based
📺 Video: ByteByteGo Channel — search "How Netflix works" or "YouTube system design"
Explanation: Generate a personalised, ranked feed of posts from people a user follows, at massive read scale.
Architecture:
Fan-out on Write: Post created → pushed to all followers' feed caches (good for users with few followers)
Fan-out on Read: Feed built at request time by pulling from followees (good for celebrities with millions of followers)
Hybrid: Combination based on follower count threshold
- Key components: Feed generation service, ranking/relevance algorithm, timeline cache (Redis), hybrid fan-out strategy
- Scaling considerations: The "celebrity problem" — fan-out on write breaks down when one account has 100M followers; hybrid approach is standard in real systems
📺 Video: Gaurav Sen — System Design Playlist — search "Twitter system design" or "News Feed design"
Explanation: Match riders with nearby drivers in real time, track live location, calculate dynamic pricing (surge).
Architecture:
Driver App ──(location updates)──► Location Service ──► Geospatial Index (Quadtree/Geohash)
│
Rider App ──(request ride)──► Matching Service ◄───────────────┘
│
└─► Pricing Service (surge calculation)
- Key components: Real-time location tracking, geospatial indexing (Quadtree or Geohash) for "nearest driver" queries, matching algorithm, dynamic pricing engine
- Scaling considerations: Location updates are extremely high-volume (every few seconds per driver) — needs efficient geospatial data structures, not naive distance calculations across all drivers
📺 Video: Gaurav Sen — System Design Playlist — search "Uber system design"
- Design a URL Shortener (TinyURL/bit.ly)
- Design Instagram
- Design Google Drive / Dropbox
- Design a Rate Limiter
- Design a Notification System (push/email/SMS)
- Design WhatsApp / a Chat Application
- Design Twitter / a News Feed system
- Design YouTube / a Video Streaming platform
- Design Uber / a Ride-Sharing system
- Design an E-commerce checkout system (Amazon-style)
- Design a Web Crawler
- Design a Distributed Cache (like Redis itself)
- Design a Parking Lot system (OOD-style, common at TCS/Microsoft)
- Design an API Rate Limiter with multiple algorithms (token bucket, sliding window)
- Design a Ticket Booking system (BookMyShow/Ticketmaster)
- Design a Search Autocomplete/Typeahead system
- Design a Payment Gateway
- Design a Distributed Job Scheduler
- Design a Content Delivery Network (CDN) from scratch
- Design a Live Comments/Polling system (real-time, high concurrency)
- Requirements: Upload photos/videos, follow users, view a feed, like/comment, search users
- High-level design: Client → API Gateway → (User Service, Post Service, Feed Service, Media Service) → Databases + Blob Storage + CDN
- Key components: Media storage (S3-like blob store) + CDN for image delivery, feed generation service (fan-out hybrid), graph database or SQL for follow relationships
- Scaling considerations: Images/videos dominate storage — CDN-first delivery; feed generation is the hardest scaling problem (same challenge as Twitter's news feed)
- Requirements: Upload/download files, folder structure, sharing/permissions, sync across devices, version history
- High-level design: Client → Sync Service → Metadata Service (folder tree, permissions) + Block Storage Service (file chunks) + Notification Service (real-time sync)
- Key components: File chunking (large files split into blocks for efficient sync/dedup), metadata database (file tree, ACLs), deduplication (same block stored once)
- Scaling considerations: Chunking + deduplication saves massive storage; conflict resolution needed for simultaneous edits across devices
- Requirements: Limit requests per user/IP to N requests per time window, distributed across multiple servers
- High-level design: Client → API Gateway (rate limiter middleware) → checks Redis counter → allows/rejects → Backend Service
- Key components: Algorithm choice — Token Bucket (smooths bursts), Sliding Window Log (precise but memory-heavy), Sliding Window Counter (good balance)
- Scaling considerations: Rate limiter state must be shared across all API servers — use a centralised store like Redis, not in-memory counters per server
- Requirements: Send push/email/SMS notifications, support scheduling, handle millions of users, retry on failure
- High-level design: Event trigger → Notification Service → Message Queue → Worker Pool → (Push Provider, Email Provider, SMS Provider)
- Key components: Message queue for async, decoupled delivery; worker pool for parallel sending; retry-with-backoff for failed deliveries; user preference service (opt-in/opt-out per channel)
- Scaling considerations: Queue-based architecture prevents notification spikes from overwhelming the system; dead-letter queues for permanently failed messages
| Tool | Purpose | Link |
|---|---|---|
| Excalidraw | Free, hand-drawn style diagramming — ideal for quick architecture sketches during practice or interviews | excalidraw.com |
| Draw.io (diagrams.net) | More structured diagramming with shape libraries for AWS/cloud icons | app.diagrams.net |
| Notion | Organise your notes, track progress, maintain your own personal system design wiki | notion.so |
💡 Tip: Practice drawing your architecture on Excalidraw out loud, as if explaining to an interviewer — this builds the muscle memory you'll need in the actual interview (many are conducted on shared virtual whiteboards).
| Channel | Best For | Link |
|---|---|---|
| Gaurav Sen | Best for fundamentals & conceptual grounding — a former Google engineer, ~718K subscribers, ~30-topic playlist covering the full basics-to-intermediate curriculum | youtube.com/@gkcs |
| ByteByteGo | Best overall — from the authors of the System Design Interview book series, 1.37M+ subscribers, exceptional visual/animated explanations of real company architectures | youtube.com/@ByteByteGo |
| Hussein Nasser | Best for backend depth — protocols, database internals, proxies, and production-level engineering explained with real examples; watch after you have fundamentals down | youtube.com/@hnasr |
| Tech Dummies Narendra L | Best for balancing High-Level Design (HLD) and Low-Level Design (LLD) in one place | Search "Tech Dummies Narendra L" on YouTube |
⚠️ Note: Channel subscriber counts and content change over time. Always check a channel's most recent uploads and pinned playlists for current, relevant content rather than relying solely on older rankings.
| Book | Author | Why Read It |
|---|---|---|
| Designing Data-Intensive Applications | Martin Kleppmann | The definitive deep-dive into how databases, distributed systems, and data pipelines actually work under the hood. Dense but foundational — read this for genuine understanding, not just interview scripts. |
| System Design Interview (Vol. 1 & 2) | Alex Xu | The most popular interview-focused system design book — structured walkthroughs of classic problems (URL shortener, chat system, news feed) in the exact format interviewers expect. |
| Week | Focus | Daily Practice |
|---|---|---|
| Week 1 | Phase 1 (Fundamentals) + Phase 2 (Databases) | 1 topic/day + write a 3-sentence summary in your own words |
| Week 2 | Phase 3 (Caching/CDN) + Phase 4 (Distributed Systems) | 1 topic/day + sketch one diagram per concept in Excalidraw |
| Week 3 | Phase 5 (Patterns) + start Phase 6 (2–3 real-world problems) | Deep-dive 1 real-world system per day; explain it out loud, recorded if possible |
| Week 4 | Remaining Phase 6 problems + mock interviews | 1 full mock system design interview every 2 days; review + refine weak areas |
Daily practice suggestion (every day, 15 minutes): Pick one concept you've already studied and explain it out loud, from memory, as if to an interviewer — no notes. This single habit builds more interview fluency than passive video-watching.
- Always clarify requirements first — ask about scale (users, requests/sec), read vs write ratio, and consistency needs before designing anything
- Start broad, then go deep — sketch the high-level architecture first, then drill into the 1-2 components the interviewer seems most interested in
- Think in trade-offs, not "correct answers" — system design has no single right answer; every choice (SQL vs NoSQL, sharding key, cache strategy) is a trade-off you should articulate
- ❌ Jumping straight into detailed architecture without clarifying requirements
- ❌ Over-engineering a simple problem with unnecessary microservices/Kafka/etc. when a monolith would suffice at the stated scale
- ❌ Silence while thinking — interviewers want to hear your reasoning process, not just a final diagram
- ❌ Ignoring non-functional requirements (availability, latency, consistency) and only focusing on features
- ❌ Not doing back-of-envelope capacity estimation (storage size, QPS) when relevant
- Narrate your thinking continuously: "I'm choosing a NoSQL store here because our access pattern is key-based lookups at high volume, and we don't need complex joins."
- Use the whiteboard/diagram tool actively — don't just talk, draw as you go
- Explicitly state assumptions: "I'll assume 100M daily active users and a 100:1 read-to-write ratio unless you'd like different numbers."
- End with a summary of trade-offs made and what you'd reconsider with more time or different constraints
- Client-Server Architecture
- HTTP/HTTPS
- DNS
- Latency vs Throughput
- CAP Theorem
- Vertical vs Horizontal Scaling
- SQL vs NoSQL
- Indexing
- Sharding
- Replication
- ACID Properties
- Redis fundamentals
- Cache invalidation strategies
- CDN basics
- Consistent Hashing
- Load Balancing
- Message Queues (Kafka/RabbitMQ)
- Event-Driven Architecture
- Microservices vs Monolith
- API Gateway
- CQRS
- Event Sourcing
- URL Shortener
- Chat System (WhatsApp)
- YouTube/Netflix
- Twitter/News Feed
- Uber/Ride-Sharing
- Practiced explaining 5+ designs out loud
- Completed at least 3 full mock interviews
- Comfortable with back-of-envelope estimation
- Can articulate trade-offs for every design decision
Scaling:
- Vertical = bigger machine | Horizontal = more machines
- CAP: pick 2 of Consistency, Availability, Partition Tolerance during a partition
Databases:
- SQL = structured, ACID, joins | NoSQL = flexible schema, horizontal scale, eventual consistency
- Sharding = split by key across machines | Replication = copy same data across machines
- Indexing speeds up reads, slows down writes
Caching:
- Cache-aside: app checks cache, falls back to DB on miss
- Write-through: write to cache and DB simultaneously
- CDN = cache static content at edge locations near users
Distributed Systems:
- Consistent hashing minimises data movement when nodes join/leave
- Load balancer types: Round-robin, Least-connections, IP-hash
- Message queues decouple producers from consumers, enable async processing
Patterns:
- Microservices = independent deployability, added operational complexity
- API Gateway = single entry point for routing, auth, rate limiting
- CQRS = separate read and write models for independent scaling
Interview Structure (memorise this flow):
- Clarify requirements (functional + non-functional)
- Estimate scale (users, QPS, storage)
- High-level design (boxes and arrows)
- Deep-dive into 1-2 components
- Discuss trade-offs and bottlenecks
- Summarise
Made with 🏗️ by Karthik Boodidha
