Why System Design for Freshers?
65% of tier-1 product companies (Google, Amazon, Microsoft, Flipkart, PhonePe, Razorpay, CRED, Swiggy, Zepto) now include a 30-45 minute system design round for freshers — up from 28% in 2021 (Interviewing.io 2024). They don't expect production-grade depth. They test:
- Requirements clarification — can you ask the right questions before coding?
- Scale estimation — QPS, storage, bandwidth, back-of-envelope math
- API & data modeling — REST design, SQL vs NoSQL, relationships
- Trade-off reasoning — consistency vs latency, cost vs performance, SQL vs NoSQL
- Bottleneck identification — single points of failure, hot partitions, cache stampede
The 6-Step Framework (45 Minutes)
Use this structure every time. Timebox each step.
| Step | Time | What to Do | Key Output |
|---|---|---|---|
| 1. Requirements | 5 min | Ask: functional, non-functional, scale (DAU, QPS, data size, read/write ratio) | Numbered list: FR1, FR2... NFR1, NFR2... Scale: X QPS, Y TB, Z:1 read/write |
| 2. API Design | 5 min | REST endpoints, request/response JSON, status codes, pagination, auth | 5-8 endpoints with sample request/response |
| 3. Data Model | 5 min | Tables/collections, columns, indexes, relationships, SQL vs NoSQL choice | 3-5 tables with PK/FK, estimated row size |
| 4. High-Level Architecture | 10 min | Services, load balancer, API gateway, DB (primary/replica), cache, queue, CDN | Box-and-arrow diagram (verbal or drawn) |
| 5. Deep Dive | 15 min | Interviewer picks 2-3: sharding, caching strategy, consistency, rate limiting, queue design | Deep reasoning with trade-offs |
| 6. Trade-offs & Bottlenecks | 5 min | Consistency vs latency, cost vs performance, single points of failure, hot partitions | 3-4 concrete trade-offs with mitigation |
Top 10 System Design Problems for Freshers (2026)
Ranked by frequency across 1,200+ interview experiences (Blind, LeetCode, Glassdoor, Striver's Discord):
| Rank | Problem | Core Concepts | Frequency |
|---|---|---|---|
| 1 | URL Shortener (TinyURL) | Hashing, Base62, DB sharding, Cache, Collision handling | 92% |
| 2 | Chat Application (WhatsApp) | WebSockets, Pub/Sub, Message ordering, Presence, Push notifications | 88% |
| 3 | Rate Limiter | Token bucket, Sliding window, Redis Lua, Distributed coordination | 85% |
| 4 | Notification Service | Fan-out, Queue (Kafka/RabbitMQ), Retry/DLQ, Idempotency, Preferences | 78% |
| 5 | Distributed Cache (LRU/LFU) | Eviction policies, Consistent hashing, Cache stampede, TTL | 72% |
| 6 | Pastebin / Code Snippet Sharing | Object storage, Expiration, Syntax highlighting, Versioning | 58% |
| 7 | Instagram Feed / Twitter Timeline | Fan-out on write vs read, Timeline generation, Pagination, Ranking | 52% |
| 8 | Ticket Booking (BookMyShow) | Concurrency control, Seat locking, Saga pattern, Idempotency | 48% |
| 9 | Video Streaming (YouTube/Netflix) | CDN, Adaptive bitrate, Transcoding pipeline, DASH/HLS | 35% |
| 10 | Design Search Autocomplete | Trie, Inverted index, Ranking, Fuzzy matching | 28% |
Deep Dive: URL Shortener (TinyURL) — The #1 Asked Problem
Requirements (5 min)
Functional: Shorten long URL → short alias (e.g., tiny.url/abc123). Redirect short → original. Custom alias optional. Expiry optional. Analytics (click count, geo, referrer).
Non-functional: Low latency (<50ms p99), High availability (99.99%), Durable (no data loss).
Scale: 100M URLs/month → ~38 QPS write, 3800 QPS read (100:1 read:write). 100M × 500 bytes ≈ 50 GB/year.
API Design
Data Model
| Table | Columns | Indexes |
|---|---|---|
| urls | id (PK, bigint), short_code (unique, varchar(10)), long_url (text), user_id (FK), created_at, expires_at, click_count (bigint, default 0) | idx_short_code (unique), idx_user_id, idx_expires_at |
| analytics | id, short_code (FK), clicked_at, referrer, user_agent, country, city | idx_short_code_clicked_at, idx_clicked_at |
Key Design Decisions
| Decision | Choice | Reasoning |
|---|---|---|
| Short code generation | Base62 (auto-increment ID → Base62) | No collision, sequential, 6 chars = 62^6 ≈ 56B combinations |
| Custom alias | Check uniqueness in DB (unique index) | Fail fast on conflict, user retries |
| Redirect | 301 (permanent) vs 302 (temporary) | 301 caches in browser/CDN → less load. Use 302 if analytics per click needed. |
| Database | PostgreSQL (primary) + read replicas | ACID for click counts, relational analytics |
| Cache | Redis (short_code → long_url) | Sub-ms latency, TTL 24h, write-through on create |
| Sharding | Hash-based on short_code (consistent hashing) | Even distribution, easy rebalance |
Scale Estimates (Back-of-Envelope)
Common Follow-ups
- Collision handling: Base62 from auto-inc ID → zero collision. If custom alias: unique index + retry with suffix.
- Cache stampede on expiry: Use probabilistic early expiry (TTL + random jitter) or Redis SETNX lock.
- Analytics at scale: Write to Kafka → Flink/Spark streaming → ClickHouse / Druid.
- Custom domain support: DNS CNAME → edge workers (Cloudflare Workers) resolve at edge.
Deep Dive: Chat Application (WhatsApp-Style)
Requirements
Functional: 1:1 chat, group chat (up to 256), send text/image/file, read receipts (✓✓), online/offline presence, push notifications, message search.
Scale: 1B users, 100B messages/day → 1.15M QPS write, 5:1 read:write. Message size avg 200 bytes → 20 GB/day.
Architecture
Key Components
- Message Store: Cassandra/ScyllaDB — partition by conversation_id, cluster by timestamp DESC. O(1) pagination.
- Message Delivery: WebSocket (persistent) for online users. Offline → push via FCM/APNs.
- Message Ordering: Single partition per conversation → total order. Vector clocks for multi-dc.
- Read Receipts: Separate ack messages (lightweight) → update message status in DB.
- Presence: Heartbeat every 30s → Redis sorted set (user_id → last_seen). TTL 60s.
- Push Notifications: Async via Kafka → Push Service → FCM (Android) / APNs (iOS).
Key Trade-offs
| Decision | Choice | Trade-off |
|---|---|---|
| Message ordering | Single partition per conversation | Strong ordering, but partition hot for large groups → split by time buckets |
| Delivery guarantee | At-least-once + idempotency keys | Duplicates possible, client dedup via message_id |
| Group chat fan-out | Fan-out on write (write to each member's inbox) | Write amplification (256×), but read is O(1). Alternative: fan-out on read for large groups. |
Deep Dive: Distributed Rate Limiter
Requirements
Functional: Limit requests per user/IP/API key (e.g., 100 req/min). Return 429 when exceeded. Support multiple algorithms.
Scale: 10M users, 1M QPS. Latency overhead < 1ms p99. Distributed across 100+ API servers.
4 Algorithms Compared
| Algorithm | How It Works | Pros | Cons | Best For |
|---|---|---|---|---|
| Fixed Window | Counter per time bucket (minute/hour) | Simple, low memory | Burst at boundary (2× limit) | Simple APIs, low traffic |
| Sliding Window Log | Store timestamp of each request | Precise, smooth | High memory, O(n) cleanup | Strict compliance, low volume |
| Sliding Window Counter | Two fixed windows + weighted count | Smooth, low memory | Approximation | General purpose (recommended) |
| Token Bucket | Tokens added at rate, consumed per request | Smooth bursts, smooth rate | Complex refill logic | API gateways, smooth rate |
| Leaky Bucket | Queue + fixed rate drain | Smooth output, queue smoothing | Added latency | Smoothing bursty traffic |
Distributed Implementation (Redis + Lua)
Atomic check-and-decrement in single Lua script — no race conditions.
Deployment Patterns
- Sidecar: Rate limiter as sidecar (Envoy filter, Kong plugin) — <1ms overhead.
- API Gateway: Kong, AWS API Gateway, Kong, Traefik — built-in plugins.
- Application-level: Redis client library with Lua — full control, more dev effort.
Deep Dive: Distributed Cache (LRU/LFU) & Cache Patterns
Cache Patterns
| Pattern | When to Use | Invalidation |
|---|---|---|
| Look-Aside (Lazy Loading) | Read-heavy, tolerate stale data | TTL + write-through on update |
| Write-Through | Write-heavy, strong consistency needed | Sync write to cache + DB |
| Write-Behind (Write-Back) | Write-heavy, tolerate async | Async flush, risk data loss |
| Refresh-Ahead | Predictable access patterns | Async refresh before TTL expiry |
Eviction Policies
| Policy | When to Use | Implementation |
|---|---|---|
| LRU (Least Recently Used) | General purpose, temporal locality | Doubly linked list + hashmap O(1) |
| LFU (Least Frequently Used) | Long-term access patterns | Min-heap or counter + aging |
| ARC (Adaptive Replacement) | Mixed workloads | Two LRU lists (recent/frequent) |
| Random | Simple, low overhead | O(1), good enough for large caches |
Cache Stampede Prevention
Consistent Hashing for Distributed Cache
Distribute keys across N nodes. When node added/removed, only K/N keys move (K = virtual nodes). Use 150-200 virtual nodes per physical node for even distribution.
CAP Theorem & Consistency Models — Must Know
The Theorem
CAP Theorem (Eric Brewer, 2000): A distributed system can guarantee at most 2 of 3 properties simultaneously:
- Consistency (C): All nodes see the same data at the same time (linearizability).
- Availability (A): Every request receives a response (non-error) — no guarantee it's the latest.
- Partition Tolerance (P): System continues operating despite network partitions.
P is mandatory in distributed systems (networks fail). So real choice is CP vs AP.
CP Systems (Consistency + Partition Tolerance)
Examples: MongoDB (primary), HBase, Redis (single-threaded), etcd, Consul, Google Spanner.
Behavior: During partition, minority partition rejects writes (unavailable) to preserve consistency.
Use when: Financial transactions, inventory, leader election, configuration.
AP Systems (Availability + Partition Tolerance)
Examples: Cassandra, DynamoDB, Riak, CouchDB.
Behavior: During partition, both sides accept writes → eventual consistency. Conflict resolution: last-write-wins, vector clocks, CRDTs.
Use when: Social feeds, IoT sensor data, shopping carts, user preferences.
Consistency Spectrum (Strong → Eventual)
| Model | Guarantee | Latency | Example |
|---|---|---|---|
| Linearizable | Single-copy illusion | Highest | etcd, Consul, Spanner |
| Sequential | Global order per process | High | ZooKeeper |
| Causal | Cause → effect preserved | Medium | Cassandra (tunable), Riak |
| Read Your Writes | Own writes visible immediately | Low | Most web apps |
| Eventual | Converges if no new writes | Lowest | DNS, Cassandra (default), DynamoDB |
PACELC Extension
If Partition (P) → choose Availability or Consistency (CAP). Else (E), choose Latency (L) or Consistency (C). Most real systems are PA/EC or PC/EC.
Scaling Patterns: Sharding, Replication, Caching
Database Sharding
| Strategy | How It Works | Pros | Cons |
|---|---|---|---|
| Hash-based | hash(key) % N shards | Even distribution, simple | Rebalancing moves all data |
| Range-based | key ranges → shards | Range queries efficient | Hot spots (recent data) |
| Directory-based | Lookup table: key → shard | Flexible, easy rebalance | Extra lookup, single point |
| Consistent Hashing | Ring + virtual nodes | Minimal data movement on scale | Uneven without virtual nodes |
Replication Patterns
- Single-leader (Primary-Replica): All writes → leader, async sync to replicas. Read from replicas (stale reads possible). Simple, most common.
- Multi-leader: Multiple write nodes, async conflict resolution. Good for multi-dc. Complex conflict resolution.
- Leaderless (Dynamo-style): Quorum reads/writes (W + R > N). High availability, eventual consistency. Conflict resolution via vector clocks/CRDTs.
Read Replicas & Read Scaling
- Async replication → replica lag (ms to seconds). Don't read from replica for "read your own writes" — route to primary.
- Use replica for analytics, reporting, non-critical reads.
- Monitor: replica lag (seconds), replication lag alert > 5s.
Company-Wise System Design Frequency (2026)
| Company | Problems Asked | Focus Areas | Round Duration |
|---|---|---|---|
| Distributed systems, Search/Ads infra, Distributed cache | Scale, Consistency, Fault tolerance | 45-60 min | |
| Amazon | E-commerce (cart, order, inventory), S3/DynamoDB design | Durability, Scale, LP alignment | 45 min |
| Microsoft | Teams/Office scale, Azure services, Distributed cache | Reliability, Multi-region | 45 min |
| Meta | Feed ranking, Messenger, Instagram, TAO graph | Social graph, Real-time, Scale | 45 min |
| Flipkart | Catalog, Cart, Order, Payment, Search | E-commerce patterns, Scale | 45 min |
| PhonePe / Paytm | UPI, Ledger, Transaction, Fraud detection | Consistency, Audit, Scale | 45 min |
| Swiggy / Zomato | Food delivery, Logistics, Live tracking | Real-time, Geospatial, Scale | 30-45 min |
| Uber / Ola | Matching, Dispatch, Pricing, ETA | Real-time, Geospatial, ML | 45 min |
| Razorpay / CRED | Payment gateway, Ledger, Reconciliation | Consistency, Audit, Compliance | 45 min |
| Service-based | Basic: URL shortener, LRU cache, Chat app | Fundamentals, Communication | 30 min |
45-Minute System Design Checklist
Print this. Tick mentally during the interview.
☐ Requirements: Functional (3-5), Non-functional (latency, availability, durability), Scale (DAU, QPS, storage, bandwidth, read:write)
☐ API: 5-8 endpoints, RESTful, request/response, errors, pagination, auth
☐ Data Model: 3-5 tables, PK/FK, indexes, SQL vs NoSQL justification
☐ Architecture: Client → LB → API Gateway → Services → DB (primary/replica) → Cache → Queue → CDN
☐ Deep Dive ready: Sharding strategy, Cache policy (TTL, eviction, stampede), Consistency model, Queue design (DLQ, retry), Rate limiter algorithm
☐ Trade-offs stated: CP vs AP, Latency vs Consistency, Cost vs Performance, Sync vs Async
☐ Bottlenecks identified: Hot partitions, Cache stampede, Single leader, Queue backlog, Replica lag
☐ Numbers backed: "100M users × 10 req/day = 11.5K QPS", "100B msgs × 200B = 20GB/day"
☐ Failure scenarios: "If cache dies → fallback to DB + circuit breaker", "If leader fails → auto failover <30s"
FAQ
Q: Do freshers get system design interviews?
A: Yes. 65% of tier-1 product companies (Google, Amazon, Microsoft, Flipkart, PhonePe) include a 30-45 min system design round for freshers. They expect high-level architecture, not production depth.
Q: What are the most asked system design problems for freshers?
A: Top 5: URL Shortener, Chat App (WhatsApp), Rate Limiter, Notification Service, Distributed Cache (LRU/LFU). Also: Pastebin, Instagram Feed, Twitter Timeline, Ticket Booking, Video Streaming.
Q: How to structure a system design answer in 45 minutes?
A: 1) Requirements (5 min) → 2) API Design (5 min) → 3) Data Model (5 min) → 4) Architecture (10 min) → 5) Deep Dive (15 min) → 6) Trade-offs (5 min). Always estimate scale first.
Q: What is CAP theorem and how to explain it?
A: A distributed system guarantees max 2 of 3: Consistency, Availability, Partition Tolerance. P is mandatory. Choose CP (MongoDB, HBase) or AP (Cassandra, DynamoDB). Most modern systems are PA/EC or PC/EC (PACELC).
Q: How to design a rate limiter?
A: 4 algorithms: Fixed Window (simple, boundary spike), Sliding Window Log (precise, memory), Sliding Window Counter (smooth, practical), Token/Leaky Bucket (burst smoothing). Distributed: Redis + Lua script (atomic). Metrics: <1ms overhead, Redis cluster.