---
title: Mastering the Top 30 System Design Interview Questions for Software and DevOps Engineers: A Comprehensive Guide with Tips and Universal Framework
created: 2026-03-06
updated: 2026-03-06
type: summary
tags: ["design", "interview", "notes", "system", "telegram"]
external: http://go/ui/posts/2121/
---

Here are the **Top 30 Must-Know System Design Interview Questions** — ranked by popularity and frequency across real interviews at top companies (FAANG, unicorns, and beyond), covering both **Software Engineer** and **DevOps Engineer** roles. Each includes **tips**, **common mistakes**, and **hints** to help you craft a strong answer.

---

## 🏆 Top 30 System Design Interview Questions

---

### **#1 — Design a URL Shortener (like TinyURL / Bitly)**
> 📊 *Asked at: Google, Meta, Amazon, Microsoft, Uber — One of the most frequently asked SD questions*

**Tips:**
- Discuss hashing strategies (Base62 encoding), collision handling, and database choice.
- Cover read-heavy vs write ratios (reads dominate).
- Add analytics (click tracking), link expiration, and rate limiting.

**🚩 Common Mistakes:**
- Ignoring collision handling for shortened URLs.
- Not discussing how to scale reads (caching layer like Redis).
- Forgetting to address custom aliases.

**💡 Hints:** Think: `API design → Hash generation → DB schema → Caching → Analytics pipeline → Scaling`

---

### **#2 — Design a News Feed / Timeline System (like Twitter/Facebook Feed)**
> 📊 *Asked at: Meta, Twitter/X, LinkedIn, Pinterest*

**Tips:**
- Discuss **fan-out on write** (push model) vs **fan-out on read** (pull model).
- Hybrid approach for celebrities vs normal users.
- Ranking/sorting algorithms (chronological vs ML-based).

**🚩 Common Mistakes:**
- Not distinguishing between push and pull models.
- Ignoring the "celebrity problem" (users with millions of followers).
- Forgetting pagination and caching.

**💡 Hints:** Think: `Post service → Fan-out service → Feed cache → Ranking service → Pagination`

---

### **#3 — Design a Chat / Messaging System (like WhatsApp / Slack)**
> 📊 *Asked at: Meta, Microsoft, Amazon, Uber*

**Tips:**
- WebSocket for real-time bidirectional communication.
- Message delivery semantics: sent, delivered, read receipts.
- Group chat architecture, message storage, and end-to-end encryption.

**🚩 Common Mistakes:**
- Using HTTP polling instead of WebSockets for real-time.
- Not handling offline message queuing and delivery.
- Ignoring group chat scaling challenges.

**💡 Hints:** Think: `Connection gateway (WebSocket) → Message queue → Chat service → Storage → Notification service`

---

### **#4 — Design a Video Streaming Platform (like YouTube / Netflix)**
> 📊 *Asked at: Google, Netflix, Amazon, Apple*

**Tips:**
- Video upload pipeline: transcoding, adaptive bitrate streaming (HLS/DASH).
- CDN distribution for global low-latency delivery.
- Recommendation engine, search indexing.

**🚩 Common Mistakes:**
- Not discussing video transcoding and multiple resolution outputs.
- Ignoring CDN and edge caching for global delivery.
- Forgetting about storage costs (object storage like S3).

**💡 Hints:** Think: `Upload → Transcoding pipeline → Object storage → CDN → Streaming protocol → Recommendation`

---

### **#5 — Design an API Rate Limiter**
> 📊 *Asked at: Stripe, Cloudflare, Amazon, Google*

**Tips:**
- Algorithms: Token Bucket, Leaky Bucket, Fixed/Sliding Window Counter.
- Distributed rate limiting with Redis.
- Where to place it: API gateway vs middleware.

**🚩 Common Mistakes:**
- Only knowing one algorithm without understanding trade-offs.
- Not addressing distributed/multi-server rate limiting.
- Forgetting about race conditions in concurrent environments.

**💡 Hints:** Think: `Algorithm choice → Distributed counter (Redis) → Rules engine → Response headers (429, Retry-After)`

---

### **#6 — Design a Ride-Sharing Service (like Uber / Lyft)**
> 📊 *Asked at: Uber, Lyft, Grab, Google*

**Tips:**
- Location-based matching (geospatial indexing with QuadTree / GeoHash).
- Real-time location tracking, ETA calculation.
- Supply-demand matching, surge pricing.

**🚩 Common Mistakes:**
- Not discussing geospatial indexing techniques.
- Ignoring real-time location updates (every few seconds from millions of drivers).
- Forgetting dispatch/matching algorithm considerations.

**💡 Hints:** Think: `Location service → Matching engine → Trip service → Payment → Notification → Map/ETA`

---

### **#7 — Design a File Storage / Sharing System (like Dropbox / Google Drive)**
> 📊 *Asked at: Google, Dropbox, Microsoft, Amazon*

**Tips:**
- Block-level deduplication and chunked uploads.
- Sync conflict resolution strategy.
- Metadata DB vs Block storage separation.

**🚩 Common Mistakes:**
- Not discussing file chunking for large files.
- Ignoring sync conflict resolution (last-write-wins vs merge).
- Missing deduplication which is a massive cost saver.

**💡 Hints:** Think: `Client sync agent → Chunking → Block storage (S3) → Metadata service → Notification (change push)`

---

### **#8 — Design a Distributed Cache System (like Redis / Memcached)**
> 📊 *Asked at: Amazon, Google, Meta, Twitter/X*

**Tips:**
- Eviction policies: LRU, LFU, TTL.
- Consistent hashing for distribution.
- Cache-aside, write-through, write-behind patterns.

**🚩 Common Mistakes:**
- Not explaining cache invalidation strategies (this is the hard part!).
- Ignoring consistent hashing for node addition/removal.
- Forgetting about thundering herd / cache stampede.

**💡 Hints:** Think: `Consistent hashing → Replication → Eviction policy → Invalidation strategy → Hot key handling`

---

### **#9 — Design a Search Autocomplete / Typeahead System**
> 📊 *Asked at: Google, Amazon, LinkedIn, Uber*

**Tips:**
- Trie data structure for prefix matching.
- Pre-computed top-K results, updated offline.
- Personalization layer and trending queries.

**🚩 Common Mistakes:**
- Building a real-time query system instead of pre-computed results.
- Not discussing latency requirements (< 100ms).
- Ignoring data collection pipeline for query frequency.

**💡 Hints:** Think: `Data collection → Trie construction (offline) → Ranking → Caching top-K → Serving layer`

---

### **#10 — Design an E-Commerce Platform (like Amazon)**
> 📊 *Asked at: Amazon, Shopify, Walmart, eBay*

**Tips:**
- Product catalog, search, cart, checkout, payment, inventory.
- Eventual consistency for cart vs strong consistency for payment.
- Inventory reservation and handling race conditions.

**🚩 Common Mistakes:**
- Not addressing inventory race conditions (double-selling).
- Ignoring payment idempotency.
- Over-simplifying the search/catalog system.

**💡 Hints:** Think: `Catalog service → Search (Elasticsearch) → Cart → Inventory reservation → Payment → Order service`

---

### **#11 — Design a Notification System (Push / SMS / Email)**
> 📊 *Asked at: Amazon, Meta, Apple, Uber*

**Tips:**
- Multi-channel delivery: push (APNs/FCM), SMS (Twilio), email (SES).
- Priority queuing, rate limiting per user, template engine.
- Delivery tracking and retry logic.

**🚩 Common Mistakes:**
- Not handling deduplication (sending the same notification twice).
- Ignoring user preferences and opt-out.
- Missing retry/DLQ for failed deliveries.

**💡 Hints:** Think: `Event trigger → Notification service → Template → Priority queue → Channel dispatcher → Tracking`

---

### **#12 — Design a Web Crawler (like Googlebot)**
> 📊 *Asked at: Google, Amazon, Microsoft*

**Tips:**
- BFS/DFS URL traversal, politeness (robots.txt, rate per domain).
- URL frontier with priority queue, deduplication (URL seen set).
- Distributed architecture with multiple crawler workers.

**🚩 Common Mistakes:**
- Not respecting robots.txt and crawl delays.
- Ignoring URL deduplication (infinite loops, spider traps).
- Not handling DNS resolution caching.

**💡 Hints:** Think: `Seed URLs → URL frontier → Fetcher workers → Content parser → URL extractor → Dedup → Storage`

---

### **#13 — Design a Key-Value Store (like DynamoDB)**
> 📊 *Asked at: Amazon, Google, Meta*

**Tips:**
- Consistent hashing, replication, conflict resolution (vector clocks).
- Read/write quorum (W + R > N).
- Gossip protocol for failure detection.

**🚩 Common Mistakes:**
- Not discussing consistency models (strong vs eventual).
- Ignoring failure detection and node recovery.
- Not explaining how partitioning works.

**💡 Hints:** Think: `Partitioning (consistent hashing) → Replication → Conflict resolution → Failure detection → Read repair`

---

### **#14 — Design a Real-Time Collaborative Editor (like Google Docs)**
> 📊 *Asked at: Google, Microsoft, Notion*

**Tips:**
- Operational Transformation (OT) or CRDT for conflict resolution.
- WebSocket for real-time sync.
- Cursor position sharing, versioning.

**🚩 Common Mistakes:**
- Not understanding OT vs CRDT trade-offs.
- Ignoring conflict resolution when two users edit the same line.
- Forgetting offline editing and sync-back.

**💡 Hints:** Think: `WebSocket gateway → Operation log → OT/CRDT engine → Document storage → Version history`

---

### **#15 — Design a Content Delivery Network (CDN)**
> 📊 *Asked at: Cloudflare, Akamai, Amazon, Netflix*

**Tips:**
- Edge servers, PoPs (Points of Presence), origin pull vs push.
- Cache invalidation, TTL, cache hierarchy (edge → regional → origin).
- DNS-based routing, anycast.

**🚩 Common Mistakes:**
- Not discussing cache invalidation strategies.
- Ignoring how DNS routing directs users to nearest edge.
- Forgetting about origin shield to protect the origin server.

**💡 Hints:** Think: `DNS resolution → Edge server lookup → Cache hit/miss → Origin pull → TTL management → Purge API`

---

### **#16 — Design a Metrics / Monitoring System (like Datadog / Prometheus)**
> 📊 *Asked at: Google, Amazon, Datadog, Uber*

**Tips:**
- Time-series database (TSDB), push vs pull metrics collection.
- Aggregation, downsampling for historical data.
- Alerting rules, dashboards.

**🚩 Common Mistakes:**
- Not discussing data retention and downsampling.
- Ignoring cardinality explosion in labels/tags.
- Forgetting alerting fatigue and alert design.

**💡 Hints:** Think: `Agents/exporters → Collection (push/pull) → TSDB → Query engine → Alerting → Dashboards`

---

### **#17 — Design a Distributed Message Queue (like Kafka / RabbitMQ)**
> 📊 *Asked at: LinkedIn, Uber, Amazon, Confluent*

**Tips:**
- Topics, partitions, consumer groups, offset management.
- At-least-once vs exactly-once delivery semantics.
- Replication for durability, ordering guarantees.

**🚩 Common Mistakes:**
- Not distinguishing between message queue (RabbitMQ) and event streaming (Kafka).
- Ignoring ordering guarantees (partition-level ordering).
- Forgetting consumer group rebalancing.

**💡 Hints:** Think: `Producer → Topic/Partition → Broker replication → Consumer group → Offset commit → DLQ`

---

### **#18 — Design a Payment System (like Stripe / PayPal)**
> 📊 *Asked at: Stripe, Square, Amazon, Google*

**Tips:**
- **Idempotency keys** are critical for payment APIs.
- Double-entry bookkeeping for financial accuracy.
- PCI compliance, tokenization.

**🚩 Common Mistakes:**
- Not discussing idempotency (duplicate charge prevention).
- Ignoring reconciliation and audit logging.
- Missing distributed transaction handling (Saga pattern).

**💡 Hints:** Think: `Payment API (idempotent) → Payment service → PSP integration → Ledger (double-entry) → Reconciliation`

---

### **#19 — Design a Location / Map Service (like Google Maps)**
> 📊 *Asked at: Google, Uber, Apple*

**Tips:**
- Map tile rendering, tile pyramid (zoom levels).
- Shortest path algorithms (Dijkstra's, A*) on road graphs.
- ETA estimation, real-time traffic overlay.

**🚩 Common Mistakes:**
- Not discussing tiling and how maps render at different zoom levels.
- Ignoring road network graph representation.
- Forgetting real-time traffic data integration.

**💡 Hints:** Think: `Tile service → Geocoding → Routing engine (graph) → Traffic service → ETA → Navigation`

---

### **#20 — Design a Ticket Booking System (like Ticketmaster / BookMyShow)**
> 📊 *Asked at: Amazon, Microsoft, Ticketmaster*

**Tips:**
- Seat reservation with distributed locking or optimistic concurrency.
- Temporary hold (TTL-based reservation) before payment.
- Handling flash sales / thundering herd.

**🚩 Common Mistakes:**
- Not handling double-booking race conditions.
- Ignoring the temporary hold + release pattern.
- Forgetting queueing for high-demand events.

**💡 Hints:** Think: `Seat map → Reservation service (lock) → TTL hold → Payment → Confirmation → Waitlist/Queue`

---

### **#21 — Design a Logging Infrastructure (like ELK / Splunk)**
> 📊 *Asked at: Amazon, Datadog, Splunk, Google*

**Tips:**
- Log collection agents → Message queue (Kafka) → Processing → Storage → Querying.
- Hot/warm/cold storage tiers for cost optimization.
- Structured logging, correlation IDs for distributed tracing.

**🚩 Common Mistakes:**
- Not addressing the massive volume of logs (TB/day).
- Ignoring storage tiering and retention policies.
- Forgetting about search indexing (Elasticsearch).

**💡 Hints:** Think: `Log agents → Kafka → Stream processing → Elasticsearch (hot) → S3 (cold) → Kibana`

---

### **#22 — Design a CI/CD Pipeline for Microservices** *(DevOps focus)*
> 📊 *Asked at: Amazon, Google, Netflix, Spotify*

**Tips:**
- Pipeline-per-service, shared templates, monorepo vs polyrepo.
- Stages: lint → test → build → artifact → deploy (staging → prod).
- Blue-green / canary deployments, automated rollback.

**🚩 Common Mistakes:**
- Not discussing rollback strategies.
- Ignoring secret management in pipelines.
- Missing contract/integration testing between services.

**💡 Hints:** Think: `Code push → Build/Test → Artifact store → Deploy (canary) → Monitor → Promote/Rollback`

---

### **#23 — Design Infrastructure as Code (IaC) at Scale** *(DevOps focus)*
> 📊 *Asked at: Amazon, HashiCorp, Google, Netflix*

**Tips:**
- Terraform state management (remote backend, state locking).
- Module reuse, environment parity (dev/staging/prod).
- Drift detection, CI/CD for infrastructure changes.

**🚩 Common Mistakes:**
- Not discussing state file management and locking.
- Ignoring blast radius (applying changes to everything at once).
- Forgetting about plan/apply workflow and approval gates.

**💡 Hints:** Think: `Modules → State backend (S3+DynamoDB) → PR-based workflow → Plan → Approve → Apply → Drift detection`

---

### **#24 — Design a Container Orchestration Platform** *(DevOps focus)*
> 📊 *Asked at: Google, Amazon (EKS), Microsoft (AKS)*

**Tips:**
- Kubernetes architecture: API server, etcd, scheduler, kubelet.
- Service mesh, ingress, autoscaling (HPA/VPA).
- Multi-tenancy, resource quotas, RBAC.

**🚩 Common Mistakes:**
- Not explaining etcd's role as the source of truth.
- Ignoring resource limits and namespace isolation.
- Forgetting about observability (metrics, logs, traces in k8s).

**💡 Hints:** Think: `Control plane → Node pools → Pod scheduling → Service discovery → Ingress → Autoscaling → Monitoring`

---

### **#25 — Design a Distributed Task Scheduler (like Cron at Scale)**
> 📊 *Asked at: Google, Uber, Airbnb, LinkedIn*

**Tips:**
- Task definition, scheduling (cron expressions), exactly-once execution.
- Leader election for scheduler HA, task queue for workers.
- Dead task detection, retry logic.

**🚩 Common Mistakes:**
- Not ensuring exactly-once execution (task runs on two nodes).
- Ignoring task prioritization and resource-based scheduling.
- Missing failure handling and dead-letter tracking.

**💡 Hints:** Think: `Scheduler (leader-elected) → Task queue → Worker pool → Execution tracking → Retry/DLQ → Dashboard`

---

### **#26 — Design a Global-Scale Database (Partitioning & Replication)**
> 📊 *Asked at: Google (Spanner), Amazon (Aurora), CockroachDB*

**Tips:**
- Horizontal partitioning (sharding) strategies: hash, range, geo-based.
- Replication: leader-follower, multi-leader, leaderless.
- Cross-region replication and consistency (linearizability).

**🚩 Common Mistakes:**
- Not discussing shard key selection and hot-spot avoidance.
- Ignoring cross-region latency and consistency trade-offs.
- Confusing replication with sharding.

**💡 Hints:** Think: `Shard key design → Partition mapping → Replication topology → Consistency protocol (Paxos/Raft) → Failover`

---

### **#27 — Design a Secrets Management System** *(DevOps focus)*
> 📊 *Asked at: HashiCorp, Amazon, Google, Netflix*

**Tips:**
- Dynamic secrets, secret rotation, lease-based access.
- Encryption at rest and in transit, audit logging.
- Integration with CI/CD, Kubernetes, and cloud IAM.

**🚩 Common Mistakes:**
- Storing secrets in code/config files.
- Not discussing rotation and automatic expiry.
- Ignoring access audit trail.

**💡 Hints:** Think: `Vault/KMS → Auth (AppRole/OIDC) → Dynamic secrets → Lease/TTL → Rotation → Audit log`

---

### **#28 — Design a Zero-Downtime Deployment Strategy** *(DevOps focus)*
> 📊 *Asked at: Amazon, Netflix, Google, Spotify*

**Tips:**
- Blue-green, canary, rolling update — know trade-offs of each.
- Feature flags for dark launches.
- Database migration compatibility (backward-compatible schema changes).

**🚩 Common Mistakes:**
- Not considering database migration as part of deployment.
- Ignoring rollback speed and detection of bad deploys.
- Forgetting about session draining.

**💡 Hints:** Think: `Deploy strategy → Health checks → Traffic shift → Monitoring/SLO → Auto-rollback trigger → DB migration compatibility`

---

### **#29 — Design a Pub/Sub System (like Google Pub/Sub / SNS+SQS)**
> 📊 *Asked at: Google, Amazon, Uber*

**Tips:**
- Topic-based vs content-based subscriptions.
- At-least-once delivery, acknowledgment, retry.
- Fan-out patterns, dead-letter queue.

**🚩 Common Mistakes:**
- Not distinguishing pub/sub from point-to-point queues.
- Ignoring message ordering guarantees.
- Missing backpressure handling for slow consumers.

**💡 Hints:** Think: `Publisher → Topic → Subscription → Push/Pull delivery → Ack/Nack → DLQ → Monitoring`

---

### **#30 — Design a Distributed Tracing System (like Jaeger / Zipkin)**
> 📊 *Asked at: Uber, Google, Datadog, Amazon*

**Tips:**
- Trace ID propagation across services (W3C Trace Context).
- Span collection, sampling strategies (head-based, tail-based).
- Storage (Elasticsearch/Cassandra), query and visualization.

**🚩 Common Mistakes:**
- Not discussing sampling (you can't store 100% of traces).
- Ignoring trace context propagation across async boundaries (queues).
- Forgetting about tail-based sampling for capturing error traces.

**💡 Hints:** Think: `Instrumentation SDK → Trace context propagation → Collector → Sampling → Storage → Query/UI → Alerting on latency`

---

## 🎯 Universal Interview Framework (Use for EVERY question)

| Step | Action |
|------|--------|
| **1. Clarify** | Ask about scale, users, latency, consistency requirements |
| **2. High-level design** | Draw boxes: clients, API, services, databases, caches |
| **3. Deep dive** | Pick 2-3 critical components and go deeper |
| **4. Trade-offs** | Compare alternatives and justify your choices |
| **5. Bottlenecks** | Identify scaling limits and propose solutions |
| **6. Operational** | Monitoring, alerting, deployment, failure handling |

## 📚 Key Concepts to Master Across All Questions

| Concept | Why It Matters |
|---------|---------------|
| **CAP Theorem** | Every distributed system makes a trade-off |
| **Consistent Hashing** | Appears in cache, DB, load balancing questions |
| **Idempotency** | Critical for payment, API, messaging systems |
| **Sharding vs Replication** | Know when and why to use each |
| **Event-Driven Architecture** | Foundation for scalable, decoupled systems |
| **SQL vs NoSQL** | Must justify your database choice every time |
| **WebSockets vs Polling** | Real-time communication design |
| **Load Balancing (L4 vs L7)** | Networking fundamentals |

Good luck with your interviews! 🚀
