System Design Interview Questions for Mid-Level Engineers (2026)

You've been coding for 3-5 years. You've built real systems at work. But system design interviews still feel different.

At the mid-level, the bar changes. You're not just drawing boxes and arrows. You're expected to make architectural decisions, defend trade-offs, and think about scale. The interviewer isn't looking for a perfect answer. They're looking for an engineer who can think like a senior.

This guide covers 10 system design questions that come up repeatedly at FAANG companies for SDE-2 and SDE-3 roles. For each question, we'll walk through the approach, key decisions, and common mistakes.

What Changes at Mid-Level

Before diving into questions, understand what's different from junior interviews:

Junior (SDE-1):

• Can you draw a basic architecture?
• Do you understand the building blocks (load balancer, cache, database)?
• Can you communicate your thoughts?

Mid-Level (SDE-2/SDE-3):

• Can you make the right architectural choices?
• Can you justify why you chose SQL over NoSQL?
• Can you handle deep dives on specific components?
• Can you think about failure modes and edge cases?

The shift is from "do you know the components?" to "can you use them correctly?"

The 5-Step Framework (Quick Recap)

Every system design question follows the same structure:

1. Clarify requirements (5 min) — What are we building? What are the constraints?
2. Estimate scale (5 min) — How many users? How much data? What's the read/write ratio?
3. High-level design (15 min) — Draw the basic architecture
4. Deep dive (15 min) — Go deeper on 2-3 components
5. Wrap up (5 min) — Discuss bottlenecks, monitoring, what you'd do differently

Question 1: Design a URL Shortener

Why it's asked: Simple enough to complete in 45 minutes, but has enough depth for follow-ups.

Requirements

• Shorten a URL to a short code (e.g., bit.ly/abc123)
• Redirect short URL to original URL
• 100M URLs created per day
• 10:1 read-to-write ratio

High-Level Design

Client → Load Balancer → API Servers → Database
                       → Cache (Redis)

Key decisions:

• Short code generation: Base62 encoding of an auto-increment ID or UUID
• Database: SQL (structured data, ACID compliance for URL creation)
• Cache: Redis for hot URLs (80/20 rule — 20% of URLs get 80% of traffic)

Deep Dive: Short Code Generation

Three approaches:

Best for interviews: Auto-increment ID with Base62. Simple, explainable, no collision issues.

Common Mistakes

• Using MD5 without explaining collision handling
• Not thinking about cache invalidation
• Ignoring analytics (how many clicks per URL?)

Question 2: Design a Chat Application (WhatsApp/Telegram)

Why it's asked: Tests real-time communication, message ordering, and offline handling.

Requirements

• 1:1 and group messaging
• Online/offline status
• Message delivery confirmation (sent, delivered, read)
• 50M daily active users

High-Level Design

Client ←→ WebSocket Servers → Message Queue → Database
                             → Presence Service (Redis)
                             → Push Notification Service

Key decisions:

• WebSocket for real-time (not polling, not SSE)
• Message queue (Kafka) for async processing and ordering
• Redis for presence (online/offline status)
• Separate read/write paths — writes go to primary DB, reads from replicas

Deep Dive: Message Ordering

Messages must arrive in order. How?

• Use a sequence number per conversation
• Single writer per conversation avoids distributed ordering problems
• Store sequence number with each message
• Client displays by sequence number, not timestamp

Common Mistakes

• Using HTTP polling instead of WebSocket
• Not handling offline messages (store and forward)
• Ignoring group message fan-out (sending to N members)

Question 3: Design a Rate Limiter

Why it's asked: Tests understanding of distributed systems, algorithms, and system reliability.

Requirements

• Limit requests per user per time window
• Support multiple rate limits (per second, per minute, per day)
• 100M requests per second across all users
• Distributed across multiple servers

Approaches

Best for interviews: Token Bucket. Explain the algorithm clearly, then discuss distributed implementation.

Deep Dive: Distributed Rate Limiting

Single-server rate limiting is easy. Distributed is hard.

• Centralized counter (Redis): Single point of failure but simple
• Local counter + sync: Faster but approximate
• Consistent hashing: Route same user to same server

Interview answer: Use Redis with atomic INCR + EXPIRE. Explain the trade-off: slight inaccuracy vs simplicity.

Common Mistakes

• Not handling Redis failure (what happens when the counter is unavailable?)
• Using local memory in a distributed system
• Not explaining the algorithm before jumping to implementation

Question 4: Design a News Feed (Twitter/Facebook)

Why it's asked: Tests fan-out strategies, caching, and handling viral content.

Requirements

• Users post updates, followers see them in a feed
• 500M users, 100M daily active
• Feed should load in < 200ms
• Celebrity accounts (10M followers) exist

Two Approaches

Fan-out on write (push model):

• When user posts, write to all followers' feeds
• Fast reads, slow writes
• Problem: celebrity with 10M followers = 10M writes per post

Fan-out on read (pull model):

• When user loads feed, fetch from all followees
• Fast writes, slow reads
• Problem: user follows 1000 people = 1000 queries per feed load

Best approach (hybrid):

• Push for regular users (< 10K followers)
• Pull for celebrities (> 10K followers)
• This is what Twitter and Facebook actually do

Deep Dive: Feed Ranking

Chronological is simple. Ranked is harder.

• Score = f(recency, engagement, relationship)
• Machine learning model ranks feed
• Cache top 500 posts per user
• Refresh cache every 5-10 minutes

Common Mistakes

• Choosing only push or only pull without explaining why
• Not handling celebrity accounts
• Ignoring feed caching strategy

Question 5: Design a Notification System

Why it's asked: Tests async processing, reliability, and multi-channel delivery.

Requirements

• Send push notifications, SMS, and emails
• Support 100M users
• Priority levels (transactional > promotional)
• Delivery tracking (sent, delivered, opened)

High-Level Design

API → Notification Service → Message Queue
                           → Push Service (APNS/FCM)
                           → SMS Service (Twilio)
                           → Email Service (SES)
                           → Delivery Tracker

Key decisions:

• Message queue for async processing (don't block on slow channels)
• Priority queues — transactional notifications skip the line
• Idempotency — same notification sent twice = dedup
• Rate limiting — don't spam users

Deep Dive: Delivery Guarantees

• At least once — prefer duplicate delivery over lost delivery
• Deduplication at the consumer level (notification ID)
• Retry with exponential backoff for failed deliveries
• Dead letter queue for permanently failed notifications

Common Mistakes

• Synchronous sending (blocks the API)
• No deduplication (user gets same notification 3 times)
• Not handling provider failures (what if Twilio is down?)

Question 6: Design a Search Autocomplete

Why it's asked: Tests trie data structures, ranking algorithms, and real-time updates.

Requirements

• Show suggestions as user types
• 100M queries per day
• Suggestions ranked by popularity
• Update suggestions in real-time

High-Level Design

Client → API Gateway → Trie Service → Cache (Redis)
                                     → Analytics Service
                                     → Update Service (Kafka)

Key decisions:

• Trie data structure for prefix matching
• Cache top suggestions per prefix (Redis)
• Background job to recompute rankings periodically

Deep Dive: Trie Optimization

Naive trie is too large for 100M queries. Optimizations:

• Compressed trie — merge single-child nodes
• Top-K per node — store only top 10 suggestions per prefix
• Sharded trie — split by first character across servers

Common Mistakes

• Using a database LIKE query instead of trie
• Not caching hot prefixes
• Ignoring ranking (just returning alphabetical results)

Question 7: Design a Distributed Cache

Why it's asked: Tests consistency, eviction policies, and distributed systems fundamentals.

Requirements

• 100K requests per second
• Sub-millisecond latency
• Support different eviction policies
• Consistent hashing for distribution

High-Level Design

Client → Cache Client → Cache Servers (sharded)
                      → Consistent Hashing Ring
                      → Replication (primary + replicas)

Key decisions:

• Consistent hashing for distribution (not modulo — handles server additions/removals)
• Eviction policies: LRU, LFU, TTL
• Replication: Primary for writes, replicas for reads

Deep Dive: Cache Consistency

Three strategies:

Interview answer: Write-through for strong consistency. Write-behind for performance. Explain the trade-off.

Common Mistakes

• Using modulo hashing (terrible when servers are added/removed)
• Not discussing cache invalidation strategy
• Ignoring cold start problem

Question 8: Design a Video Streaming Platform (YouTube)

Why it's asked: Tests storage, CDN, and transcoding pipelines.

Requirements

• Upload and stream videos
• 500M daily active users
• Support multiple resolutions
• Video recommendations

High-Level Design

Upload → Transcoding Service → Object Storage (S3)
                              → CDN (CloudFront)
                              → Metadata DB (SQL)
                              → Recommendation Service

Key decisions:

• Transcoding: Convert uploaded video to multiple resolutions (1080p, 720p, 480p)
• CDN: Serve video from edge locations close to users
• Object storage: S3 for video files (not database)
• Adaptive bitrate: Client switches quality based on bandwidth

Deep Dive: Transcoding Pipeline

• Upload → Message Queue → Transcoding Workers → Multiple output files
• Workers process in parallel (one per resolution)
• Progress tracking via WebSocket
• Failed jobs retry with exponential backoff

Common Mistakes

• Storing video files in a database
• Not using CDN for delivery
• Ignoring transcoding cost and time

Question 9: Design a Payment System

Why it's asked: Tests idempotency, consistency, and handling money carefully.

Requirements

• Process payments between users
• Support credit cards, UPI, wallets
• 10M transactions per day
• 99.99% reliability

High-Level Design

Client → Payment API → Payment Service → Payment Provider (Razorpay/Stripe)
                                        → Ledger Service (double-entry bookkeeping)
                                        → Notification Service

Key decisions:

• Idempotency keys — same request twice = same result
• Double-entry bookkeeping — every transaction has debit and credit
• Retry logic — exponential backoff for provider failures
• Reconciliation — periodic check that our ledger matches provider's

Deep Dive: Idempotency

Payment systems must be idempotent. User clicks "Pay" twice? Same result.

• Client generates unique idempotency key per transaction
• Server checks if key exists → return cached result
• If not, process payment, store result with key
• Redis or DB for idempotency key storage

Common Mistakes

• Not implementing idempotency (double charges)
• Storing card details (PCI violation — use tokenization)
• No reconciliation process

Question 10: Design a Job Scheduler (Cron on Steroids)

Why it's asked: Tests distributed systems, fault tolerance, and exactly-once execution.

Requirements

• Schedule jobs at specific times
• 1M jobs per day
• Support retries on failure
• Distributed across multiple servers

High-Level Design

Client → Scheduler API → Job Queue (Kafka)
                       → Worker Pool → Execution
                       → State Store (DB)
                       → Dead Letter Queue

Key decisions:

• Job queue for distribution (not single-server cron)
• At-least-once execution with idempotent jobs
• Dead letter queue for permanently failed jobs
• Sharding by job type for parallel execution

Deep Dive: Exactly-Once Execution

Distributed systems can't guarantee exactly-once. But we can get close:

• Use idempotent job design (running twice = same result)
• Lock mechanism (only one worker picks up a job)
• State tracking (pending, running, completed, failed)
• Retry with exponential backoff

Common Mistakes

• Using a single-server cron (not distributed)
• Not handling worker crashes (job stuck in "running" state)
• No dead letter queue (failed jobs retry forever)

How to Practice

Reading about these questions isn't enough. You need to practice explaining them out loud.

1. Draw the architecture on paper or Excalidraw
2. Time yourself — 45 minutes per question
3. Talk through your decisions — explain why you chose X over Y
4. Handle follow-ups — "What happens when this fails?" "How does this scale?"
5. Compare trade-offs — there's no perfect answer, only trade-offs

The best way to practice is with someone who can challenge your assumptions. A mock interview with an AI interviewer like InterviewSkool forces you to articulate your thinking under pressure — which is exactly what the real interview tests.

Quick Reference: Decision Cheat Sheet

Practice What You Learned

Ready to put this into practice? Try a mock coding interview or mock system design interview with an AI interviewer who challenges your thinking and scores your communication.

What's Next?

After mastering these 10 questions, you'll have the foundation for any system design interview. The key isn't memorizing solutions — it's understanding the trade-offs so you can reason through new problems.

Want to practice these in a real interview setting? Try a mock system design interview with an AI interviewer who challenges your decisions and scores your communication.