System design is the round that separates senior engineers from everyone else — and increasingly, it's appearing in mid-level interviews at product companies too. The good news: unlike DSA, system design has a learnable framework. If you follow this 30-day plan with genuine effort, you'll go from 'I don't know where to start' to handling any real-world system design problem confidently.
The Framework First: How to Approach Any System Design Question
Before diving into specific systems, learn the interview framework. Every system design answer should follow this structure: 1. Clarify requirements (5 min): What features? Read-heavy or write-heavy? How many users? Consistency requirements? 2. Estimate scale (3 min): Users, QPS (queries per second), storage, bandwidth. 3. High-level design (10 min): Draw the major components — clients, API servers, databases, caches, queues. 4. Deep dive (15 min): Pick 2-3 interesting components and explain your design decisions in detail. 5. Address bottlenecks (5 min): Where does your system fail at 10x scale? How would you fix it?
This framework works for URL shorteners, Twitter feeds, Uber backends, and YouTube — master the structure and you'll never be completely lost in an interview again.
Days 1–7: Core Concepts You Must Know Cold
Week 1 is pure concepts. Don't skip this to jump to 'cool' system designs — you'll hit walls later. Networking basics: DNS resolution, load balancers (L4 vs L7), CDNs (what content they cache, how TTL works). APIs: REST vs GraphQL vs gRPC, API gateway patterns, rate limiting algorithms (token bucket, sliding window). Databases: SQL vs NoSQL (when to use each), ACID vs BASE, read replicas, database sharding strategies (range-based, hash-based, directory-based).
Caching: in-memory (Redis, Memcached), cache eviction (LRU, LFU, TTL), cache invalidation patterns (write-through, write-back, cache-aside), and cache stampede. Message queues: Kafka vs RabbitMQ, when to use async messaging, exactly-once semantics, consumer groups. Spend 2 hours per day reading. Best resources: ByteByteGo Newsletter (free), the ByteByteGo book, and Alex Xu's System Design Interview Vol 1.
Days 8–15: Learn 6 Core System Designs
Week 2: study and practice these 6 systems — they cover the patterns that appear in 80% of interviews. Day 8-9: URL Shortener (tinyURL) — teaches: hash generation, NoSQL vs SQL for key-value, redirection, analytics. Day 10-11: Rate Limiter — teaches: token bucket/sliding window algorithms, Redis for distributed state, API gateway placement. Day 12-13: Design Twitter/Instagram Feed — teaches: fan-out on write vs fan-out on read, timeline generation, denormalization for performance.
Day 14: Distributed Key-Value Store (like DynamoDB) — teaches: consistent hashing, replication, CAP theorem, quorum reads/writes. Day 15: YouTube/Netflix — teaches: CDN, video transcoding pipelines, chunked uploads, recommendation systems at high level. For each system: draw the diagram from memory, then compare to a reference solution (ByteByteGo, Educative, or Engineering blogs). Note where your design differed and why.
What Indian Product Companies Actually Ask in System Design
Here's the inside scoop on what specific Indian companies focus on, based on candidate reports from 2023-2024 hiring cycles. Flipkart loves e-commerce-flavored questions: design the cart service, design flash sale handling (Big Billion Day patterns), design product search. Expect deep dives on cache warming, inventory locking, and handling 100K QPS spikes during sales. They pay ₹45-70 LPA for SDE-2 and ₹80 LPA-1.2 Cr for SDE-3 with system design being 40% of the bar.
Swiggy and Zomato ask delivery-specific designs: assignment algorithms for delivery partners, real-time order tracking, surge pricing systems. Their interviewers care a lot about geospatial indexing (geohashing, S2 cells, quadtrees) — most candidates skip this and bomb the round. Razorpay and PhonePe focus on payments: design idempotent payment APIs, design a wallet system, design fraud detection. Expect questions on exactly-once semantics, distributed transactions, and PCI compliance trade-offs.
Microsoft India, Google Bangalore, and Amazon ask classical FAANG-style designs but with a twist — they probe deeper on trade-offs. Saying "I'd use Kafka" isn't enough; you need to explain why not Kinesis, why not RabbitMQ, what happens if a partition leader dies. Before your interview, browse jobs at your target company and read their engineering blog — Flipkart Tech Blog, Swiggy Bytes, and Razorpay Engineering all post real architecture decisions that interviewers reference.
Days 16–22: Go Deep on Databases and Distributed Systems
This week is about the questions that separate good candidates from great ones: Why would you choose Cassandra over PostgreSQL for a specific use case? How do you handle eventual consistency in a distributed system? What is a distributed transaction and why is it hard?
Topics to master: Database indexing (B-tree internals at a high level), database partitioning strategies, the CAP theorem (Consistency, Availability, Partition tolerance — and why you can only guarantee 2 of 3), the PACELC model (more practical than CAP), distributed locking (Redis SETNX, Zookeeper), leader election, and consensus algorithms (Paxos/Raft at a conceptual level). You don't need to implement Raft — you need to understand why it exists and what problem it solves.
Real Numbers You Should Memorize Before Walking In
Interviewers love when you throw out concrete estimates instead of vague hand-waving. Memorize these baseline numbers and you'll sound 10x more credible. Latency numbers every engineer should know: L1 cache reference is 0.5 nanoseconds, main memory reference is 100 ns, SSD random read is 150 microseconds, network round trip within same datacenter is 0.5 ms, and a round trip from Mumbai to US-East is roughly 200 ms.
Throughput baselines: a single MySQL instance handles roughly 1K-5K QPS for writes, Redis can do 100K+ ops/sec on commodity hardware, Kafka can handle millions of messages per second across a cluster, and a well-tuned Nginx load balancer pushes 50K-100K requests/sec per node. Storage estimates: a tweet is roughly 300 bytes, a high-quality photo is 2-5 MB, an HD minute of video is around 50 MB, and a typical user profile is 1-2 KB.
When asked "design Instagram for 500M users", you should instantly compute: if 10% post daily and average 2 photos at 3 MB each, that's 300 TB/day of new storage. At ₹2/GB/month for S3-equivalent storage in India, that's ₹600K/day in storage costs — numbers like this win interviews. The same way you'd benchmark salary before negotiating, benchmark your back-of-envelope math before the whiteboard.
Days 23–27: Practice Mode — 5 Full Design Sessions
Stop reading. Start designing. Use a whiteboard or Excalidraw. Set a timer for 45 minutes and design: Day 23: Google Drive / Dropbox. Day 24: Uber / Ola ride-hailing backend. Day 25: WhatsApp messaging system. Day 26: Search Autocomplete / Typeahead. Day 27: Hotel Booking system (like MakeMyTrip/Booking.com).
For each, follow the interview framework from Day 1. After designing, compare your solution to a reference (search 'system design [name] blog' or use ByteByteGo). Be honest about gaps. The goal isn't a perfect design — it's a structured, reasoned design that you can defend and evolve during a 45-minute conversation.
The 7 Mistakes That Tank System Design Interviews
After analyzing rejection feedback from hundreds of Indian engineers, the same mistakes repeat. Mistake 1: Jumping to solutions without clarifying requirements. The interviewer says "design Twitter" and you start drawing boxes. Wrong. Spend 5 minutes asking: how many DAUs, what features (DMs? video? ads?), read or write heavy, global or regional. Mistake 2: Ignoring scale estimates. Vague answers like "we'll use a database" without computing storage or QPS make you look junior.
Mistake 3: Over-engineering for day one. Don't introduce Kafka, Cassandra, Elasticsearch, and Spark for an MVP serving 10K users. Start simple, then scale. Mistake 4: Memorizing solutions without understanding. If you can only recite the "standard" URL shortener answer but can't adapt when the interviewer says "now make it work offline", you'll fail. Mistake 5: Ignoring non-functional requirements. Latency targets, availability SLAs, consistency requirements — bring these up yourself.
Mistake 6: Not addressing failure modes. What if a database node dies? What if the cache goes down? What if a region loses connectivity? Senior interviewers always probe failure scenarios. Mistake 7: Poor communication. This is huge. Talk through your thinking, draw clean diagrams, label arrows with the protocol (HTTP, gRPC, async). Many strong engineers fail because they design well but communicate chaotically. Just like you'd check ATS score to make sure your resume is parseable, structure your verbal design so it's "parseable" by the interviewer.
Days 28–30: Mock Interviews and Weak Area Review
Days 28-29: Do 2-3 mock system design interviews with peers (use Pramp or find a study partner on Discord communities like TechInterviewHandbook or NeetCode). The act of explaining your design out loud, handling follow-up questions, and managing the 45-minute clock is very different from reading or writing — you need to practice the verbal aspect.
Day 30: Review your top 5 weakest areas. For most candidates, this is: distributed databases (how sharding actually works), consistency models (eventual vs strong vs causal), and estimating QPS/storage accurately. Before any interview, re-read the system designs for the company's actual products — Google interviewers love discussing Google-scale systems, Amazon interviewers care about AWS services, Swiggy/Zomato interviewers may ask about food delivery-specific challenges.
Resources That Are Actually Worth Your Time (and Money)
There's a lot of noise in the system design prep space. Here's what's worth it for Indian engineers on different budgets. Free tier: ByteByteGo's newsletter on LinkedIn (Alex Xu posts 2-3 system breakdowns weekly), the GitHub repo donnemartin/system-design-primer (still the gold standard for fundamentals), Gaurav Sen's YouTube channel (his Indian-context explanations are excellent), and engineering blogs from Uber, Netflix, Discord, and Cloudflare.
Paid (₹2,000-8,000): Alex Xu's "System Design Interview" Vol 1 and Vol 2 (around ₹3,500 combined on Amazon India) are mandatory reading. Educative.io's "Grokking the System Design Interview" costs roughly ₹6,000/year and is genuinely comprehensive. Skip generic Udemy courses — most are outdated.
Premium (₹15,000+): 1-on-1 mock interviews on Interviewing.io or interviewbit.com cost ₹2,000-5,000 per session with ex-FAANG engineers. Worth it for the final week before high-stakes interviews. Avoid expensive 6-month "bootcamps" priced at ₹50K-1L — they recycle free content. Once you've practiced enough designs, also practice interviews for behavioral and deep-dive technical rounds, because system design is only one part of the loop at most companies.
FAQ
How much system design knowledge do I need for a 3-year experience SDE role in India?
For 3 years experience, you're typically applying for SDE-2 roles at product companies paying ₹25-45 LPA. Companies like Flipkart, Swiggy, Razorpay, and PhonePe will ask one full system design round (45-60 min) plus design-flavored questions in coding rounds. You need to confidently design moderate-complexity systems — URL shortener, rate limiter, news feed, basic chat — and articulate trade-offs. Deep distributed-systems knowledge (Raft, vector clocks) isn't expected, but you should know CAP theorem, sharding strategies, caching patterns, and basic NoSQL vs SQL trade-offs cold. This 30-day plan is calibrated exactly for this level.
Can I crack system design without prior distributed systems experience?
Yes, and most candidates do. Roughly 70% of engineers at Indian product companies came from service-based backgrounds (TCS, Infosys, Wipro, Accenture) or product companies where they worked on monoliths, not distributed systems. The interview tests structured thinking and knowledge of patterns, not whether you've personally built Cassandra. Read the engineering blogs from Uber, Netflix, and Discord — they explain real production systems in interview-friendly format. After 30 days of focused study and 10+ mock designs, even someone with zero distributed systems work experience can clear interviews at companies paying ₹40-60 LPA.
Should I draw diagrams or talk through the design in a virtual interview?
Both, but lead with diagrams. Use Excalidraw, Miro, or even the interviewer's collaborative whiteboard — share your screen and draw boxes for components (clients, load balancer, API servers, databases, caches, queues), then arrows showing data flow. Label arrows with the protocol (HTTPS, gRPC, async via Kafka). Talk continuously while drawing, narrating your reasoning. Silence kills virtual interviews. Practice this combo at home with a screen recorder — watch yourself back and you'll be shocked at how often you go silent or draw messy diagrams. Clean, labeled diagrams plus clear narration consistently beat candidates with deeper knowledge but worse communication.
How is system design different for backend vs full-stack vs ML engineer roles?
For backend engineers, expect classical distributed systems questions: scalability, databases, caching, queues, microservices. This guide is optimized for this track. For full-stack roles at companies like Razorpay or CRED, system design is lighter — they may ask you to design a feature end-to-end including frontend state management, API design, and basic backend, but not deep distributed systems. For ML engineers, system design morphs into ML system design: feature stores, model serving, A/B testing infrastructure, batch vs online inference, drift detection. Read Chip Huyen's "Designing Machine Learning Systems" — it's the equivalent of Alex Xu's book for ML roles and is essential for any AI/ML interview at Indian product companies.
Bottom Line
- Follow the 5-step framework (clarify, estimate, design, deep dive, bottlenecks) for every single question — structure beats raw knowledge in interviews
- Spend Week 1 on fundamentals — caching, databases, queues, networking. Skipping this is the number 1 reason people fail despite knowing "popular" system designs
- Memorize latency and throughput numbers so your back-of-envelope estimates sound concrete instead of vague
- Practice verbally with mocks in the final week — most rejections come from poor communication, not poor knowledge
- Tailor your prep to the company — read their engineering blog, understand their domain (payments, food delivery, e-commerce), and reference their actual systems during the interview