System Design Basics for Interview Preparation

What system design interviews test

System design interviews assess whether you can translate ambiguous requirements into a working architecture — APIs, data models, components, and scaling strategy. They appear for SDE-2 and above at product companies, and increasingly for strong SDE-1 candidates.

You are not expected to design Google-scale systems in 45 minutes. You are expected to think structured, communicate trade-offs, and go deep where the interviewer probes.

The interview framework (45 minutes)

Follow this sequence every time:

• Step 1 (5 min): Clarify requirements — functional and non-functional.
• Step 2 (5 min): Back-of-envelope estimation — users, QPS, storage.
• Step 3 (10 min): High-level design — boxes and arrows, major components.
• Step 4 (15 min): Deep dive — data model, API design, one scaling challenge.
• Step 5 (10 min): Trade-offs, bottlenecks, and how you would iterate.

Core building blocks to know

You should explain each of these in 2–3 sentences:

• Load balancers (L4 vs L7).
• Caching (CDN, application cache, Redis use cases).
• Databases (SQL vs NoSQL, when to pick each).
• Message queues (Kafka, RabbitMQ, SQS — async processing).
• Microservices vs monolith — trade-offs, not dogma.
• Replication and sharding for database scaling.
• Consistent hashing for distributed caches.
• CAP theorem — practical implications, not theory recitation.

Starter problems to practice

Master these before moving to harder designs:

• URL shortener (TinyURL) — hashing, collisions, analytics.
• Rate limiter — token bucket, sliding window, distributed counters.
• Notification system — push/email/SMS, queues, fan-out.
• Chat system — WebSockets, message ordering, presence.
• News feed — fan-out on write vs fan-out on read.
• Pastebin — object storage, expiration, access control.

Data modeling basics

Start with entities and relationships. Choose SQL for structured queries and transactions; NoSQL for flexible schemas, high write throughput, or document storage.

• Define primary keys, indexes, and access patterns before schema.
• Normalize first, denormalize for read performance when measured.
• Consider hot vs cold data separation.
• Plan for idempotency in write APIs.

Common mistakes

These cost candidates the offer:

• Jumping to microservices and Kubernetes without justification.
• Ignoring non-functional requirements (latency, availability, consistency).
• No numbers — always estimate scale.
• Designing in silence — narrate your thinking.
• Over-engineering v1 — start simple, scale when asked.
• Not identifying the bottleneck when the interviewer asks 'what breaks first?'

4-week system design prep plan

Week 1: building blocks. Week 2: 3 starter problems. Week 3: 3 medium problems (Twitter, Uber, Dropbox). Week 4: timed mocks with peer or AI feedback on InterviewVeda.