System design interviews are asked differently at different companies and levels. At FAANG companies for senior roles, they're deep 60-minute architecture discussions. At mid-tier IT companies for freshers, they're often surface-level questions about databases, APIs, and basic scaling concepts.
Know which level you're at before you prepare.
What Interviewers Are Actually Evaluating
System design is not a test of whether you've memorized every architecture pattern. It is a test of how you think. Interviewers want to see: Can you ask clarifying questions before designing? Can you identify trade-offs rather than claiming your solution is universally correct? Do you know when to use which technology and why?
A candidate who says "I would use a relational database here because the data has strong referential integrity and we need ACID guarantees, though this limits horizontal scaling" shows more depth than one who says "use PostgreSQL everywhere."
The RESHADED Framework
For any system design question, structure your answer with these components:
- *R — Requirements:** Clarify functional (what the system must do) and non-functional (scale, latency, consistency) requirements before drawing a single box. "How many users per day? Is this read-heavy or write-heavy? Do we prioritize consistency or availability?"
- *E — Estimation:** Back-of-envelope numbers. If 10 million daily active users each make 3 requests per day, that's ~350 requests per second. This drives your architecture choices.
- *S — Storage:** What data needs to be stored? What is the access pattern? SQL vs NoSQL depends on: structure of data, query patterns, scale, and consistency requirements.
- *H — High-Level Design:** Draw the major components: client, load balancer, application servers, database, cache, CDN. Keep it simple at first.
- *A — APIs:** Define 2–3 key API endpoints. What parameters do they take? What do they return?
- *D — Deep Dive:** Pick 1–2 components and go deeper — the most interesting or the most problematic. Caching strategy, database sharding, message queue design.
- *E — Edge Cases:** What happens during failure? What if a service goes down? How do you handle traffic spikes?
- *D — Deployment:** How does this get deployed? Monolith vs microservices? Containerized? Cloud provider?
Commonly Asked Systems
- *URL shortener (bit.ly):** Key concepts: hash generation, redirect performance, analytics, expiry. Database: primarily read-heavy, NoSQL for fast lookup.
- *Chat application:** Key concepts: websockets vs. long polling, message ordering, offline delivery, read receipts. Message queue (Kafka) for reliability.
- *Feed system (social media):** Key concepts: fan-out on write vs. fan-out on read, ranked feeds, caching hot users, eventual consistency.
For Freshers: What Level is Expected
If you're interviewing at TCS, Infosys, Wipro as a fresher, you will not be asked to design Twitter at scale. You might be asked: "How would you design a simple library management system?" or "Explain what happens when you type google.com in your browser."
Know: what a database is and when to use SQL vs NoSQL at a basic level, what an API is, what a server does, what caching does. That is sufficient.
Practice
The only way to improve at system design is to practice saying your designs out loud. VividMock's technical round will probe your architecture thinking with follow-up questions, helping you identify gaps in your reasoning before a real interview exposes them.