Every System Design Question You'll Get at FAANG, Ranked by Difficulty
30 system design interview questions ranked by difficulty from beginner to staff level. Each question includes key concepts tested and why it's asked — covering URL shorteners to distributed locking.
These 30 questions represent the most frequently asked system design problems across FAANG and top tech companies.
The ranking reflects consensus difficulty across all sources, calibrated against the seniority expectations reported by interviewers and candidates.
If you are preparing for a system design interview, this guide will help you thoroughly.
Beginner Tier: Questions 1–10
These questions test foundational distributed systems thinking. They have well-defined scope, limited components, and are appropriate for junior-to-mid-level candidates (L3–L4).
Most can be reasonably designed in a 35-minute interview without deep infrastructure expertise.
1. Design a URL Shortener like TinyURL or Bit.ly
Why this difficulty: This is the single most universal system design question. It appears in literally every major prep resource and has been reported at Google, Amazon, Meta, and dozens of other companies. It has a small, well-defined scope with clear inputs and outputs, making it the “Hello World” of system design.
Key concepts tested: Base62/Base64 encoding, hashing and collision handling, key-value store design, 301 vs. 302 redirects, caching with read-heavy workloads, database partitioning, analytics tracking, and capacity estimation.
2. Design a Rate Limiter
Why this difficulty: Narrow scope with a single clear objective. Reported at Amazon, Google, Uber, Stripe, Microsoft, Atlassian, and Pinterest; one of the most cross-company questions. It tests whether you understand API infrastructure without requiring complex multi-service architecture.
Key concepts tested: Token bucket, leaky bucket, sliding window, and fixed window counter algorithms; Redis for distributed state; HTTP 429 responses; rate limiting at different layers (client, API gateway, application); race conditions in distributed environments.
3. Design a Distributed Cache
Why this difficulty: Focused infrastructure problem with well-understood trade-offs. Frequently asked as a building-block question to assess understanding of caching fundamentals before tackling larger system designs.
Key concepts tested: Consistent hashing for key distribution, eviction policies (LRU, LFU, TTL), cache-aside vs. write-through vs. write-back strategies, Redis and Memcached architecture, cache stampede prevention, and hot key handling.
4. Design Pastebin
Why this difficulty: Similar to URL shortener but with additional storage considerations.
Limited feature scope keeps complexity manageable.
Key concepts tested: Object/blob storage for text content, unique URL generation, expiration and cleanup policies, read-heavy optimization, access control, and content size limits.
5. Design a Unique ID Generator for Distributed Systems
Why this difficulty: A pure infrastructure question with constrained scope. Tests understanding of distributed coordination without requiring full system architecture.
Key concepts tested: Twitter Snowflake ID architecture, UUID trade-offs, database auto-increment limitations, clock synchronization and NTP drift, ordering guarantees, and timestamp-embedded IDs.
6. Design a Notification System
Why this difficulty: Moderate breadth but each component is straightforward. Reported at Google, Amazon, Airbnb, Pinterest, Uber, and Instacart.
Tests multi-channel thinking without deep algorithmic complexity.
Key concepts tested: Push notification services (APNs, FCM), SMS and email delivery, message queue architecture, retry and failure handling, user preference management, rate limiting notifications, and template systems.
7. Design a Web Crawler
Why this difficulty: A classic question that appears in all four major prep platforms.
The core algorithm (BFS) is simple, but the distributed version introduces meaningful complexity.
Key concepts tested: BFS/DFS traversal strategies, URL frontier and prioritization, politeness policies and robots.txt, URL deduplication (bloom filters, checksums), distributed crawling coordination, DNS resolution caching, and handling traps (infinite loops, spider traps).
8. Design a Content Delivery Network (CDN)
Why this difficulty: It’s a well-understood infrastructure pattern with clear architectural components. Tests knowledge of a critical building block used in nearly every large-scale system.
Key concepts tested: Edge server placement, cache invalidation strategies (TTL, purge, versioning), origin server pull vs. push models, DNS-based geographic routing, load balancing, TLS termination, and cost optimization.
9. Design a Key-Value Store
Why this difficulty: While the basic version is simple, this question scales in difficulty based on how deep the interviewer probes.
At the beginner level, it tests fundamental storage and retrieval concepts.
Key concepts tested: CAP theorem trade-offs, consistent hashing for partitioning, data replication strategies, gossip protocol for failure detection, Merkle trees for consistency checking, read/write paths, and tunable consistency (quorum reads/writes).
10. Design a Pub/Sub Messaging System like Kafka
Why this difficulty: The core abstraction (publishers, topics, subscribers) is intuitive. Complexity emerges in delivery guarantees and scaling, but the high-level design is approachable for candidates with basic distributed systems knowledge.
Key concepts tested: Topics and partitions, brokers and replication, consumer groups and offset management, delivery semantics (at-most-once, at-least-once, exactly-once), message ordering guarantees, and backpressure handling.
Intermediate Tier: Questions 11–20
These questions require designing multi-component systems with meaningful trade-offs. They test the ability to navigate ambiguity, reason about fan-out strategies, handle real-time requirements, and make architecture decisions under constraints.
Appropriate for mid-level to senior candidates (L4–L5).
11. Design a Chat System like WhatsApp or Facebook Messenger
Why this difficulty: Appears across all major sources and reported at Meta, Google, and multiple FAANG companies. The real-time delivery requirement, online/offline state management, and group chat mechanics push this firmly into intermediate territory. Multiple communication protocols must be evaluated.
Key concepts tested: WebSocket connections and long polling, message queues for asynchronous delivery, online presence and heartbeat systems, end-to-end encryption, message ordering and delivery receipts, group chat fan-out, push notification fallback, and media message handling.
12. Design a News Feed System like Facebook or Twitter’s Timeline
Why this difficulty: The fan-out problem is the central challenge; the “celebrity problem” where a user with millions of followers posts content creates a genuinely hard scaling decision. This is the canonical question for understanding feed architecture.
Key concepts tested: Fan-out on write vs. fan-out on read (the defining trade-off), hybrid approaches for celebrity accounts, feed ranking algorithms, caching pre-computed feeds, social graph traversal, content deduplication, and real-time feed updates.
13. Design a Search Autocomplete/Typeahead System
Why this difficulty: Reported at Google, Meta, and Netflix. Requires understanding of specialized data structures (tries) and real-time performance requirements.
The distributed caching layer and ranking algorithm add meaningful complexity beyond simple prefix matching.
Key concepts tested: Trie data structure and prefix matching, frequency-based ranking, distributed caching of top suggestions, real-time updates vs. offline computation, personalization, multi-language support, and latency requirements (<100ms response time).
14. Design YouTube
Why this difficulty: Video transcoding pipelines, adaptive bitrate streaming, and global content delivery create a multi-layered problem that tests breadth of knowledge across storage, processing, and delivery.
Key concepts tested: Video upload and transcoding pipeline (DAG-based), adaptive bitrate streaming (HLS/DASH), CDN architecture for video delivery, blob storage for video files, metadata database design, thumbnail generation, recommendation engine integration, and copyright detection.
15. Design Google Drive or Dropbox
Why this difficulty: Reported at Google, Meta, Amazon, Microsoft, and Dropbox itself. The file synchronization challenge, ensuring consistency across multiple devices with conflict resolution, makes this more complex than simple file storage.
Key concepts tested: File chunking and deduplication, sync agents and conflict resolution (last-writer-wins vs. merge), block-level storage, metadata service, pre-signed URLs for upload/download, notification service for changes, versioning, and offline editing support.
16. Design Instagram
Why this difficulty: The single most reported system design question at Meta according to IGotAnOffer’s analysis of 100+ Glassdoor reports. Combines photo/video storage, feed generation, and social features. More constrained than designing all of Facebook, making it a well-scoped intermediate challenge.
Key concepts tested: Photo and short-video storage pipeline, CDN for media delivery, news feed generation (fan-out strategies), follower/following graph, Stories feature (ephemeral content with TTL), Explore/discovery page, like and comment systems, and content moderation.
17. Design Uber or Lyft
Why this difficulty: It’s reported at Uber, Meta, and multiple FAANG companies. The real-time location tracking, driver-rider matching, and ETA computation create a complex multi-service system with strict latency requirements.
Key concepts tested: Geospatial indexing (geohashing, H3 hexagons, QuadTree), real-time location tracking via WebSockets, driver-rider matching algorithms, ETA calculation using graph algorithms, surge pricing mechanics, trip state machine, payment integration, and dispatch service design.
18. Design a Proximity/Location-Based Service like Yelp
Why this difficulty: More focused than Uber (no real-time tracking), but the geospatial querying problem is non-trivial. Tests specialized knowledge of spatial data structures that many candidates haven’t encountered.
Key concepts tested: Geohashing and precision levels, QuadTree construction and querying, spatial indexing in databases (PostGIS, Elasticsearch), read-heavy optimization, business profile storage, search radius handling, and result ranking by relevance and distance.
19. Design TikTok
Why this difficulty: A modern question increasingly asked at FAANG companies (2024–2026). Combines video processing challenges (similar to YouTube) with a recommendation-first architecture that prioritizes content discovery over social graph.
Key concepts tested: Short-form video upload and processing pipeline, recommendation engine as the core product (not just a feature), content moderation at scale, CDN for video delivery, creator tools and analytics, duet/stitch features requiring video composition, and virality mechanics.
20. Design a Hotel Reservation System
Why this difficulty: Reported at Amazon, Booking.com, and Square. The double-booking prevention problem is the central challenge. It tests understanding of concurrency control, distributed transactions, and inventory management under high contention.
Key concepts tested: Inventory management and availability calendars, double-booking prevention (optimistic vs. pessimistic locking), ACID transactions for reservations, search by location/date/price, overbooking strategies, payment hold and confirmation flows, and cancellation policies.
Advanced Tier: Questions 21–30
These questions demand deep expertise in distributed systems, consensus protocols, low-latency architecture, or complex multi-party coordination. They feature ambiguous requirements, require navigating multiple hard trade-offs simultaneously, and are appropriate for senior-to-staff engineers (L5–L6+).
Interviewers expect candidates to discuss failure modes, regulatory constraints, and innovative approaches.
21. Design Google Maps
Why this difficulty: Reported at Google and Uber.
Combines graph algorithms, geospatial data management, real-time traffic integration, and massive map tile serving into one of the broadest system design problems.
The routing engine alone (Dijkstra’s/A* over billions of road segments) is a substantial sub-problem.
Key concepts tested: Graph algorithms for routing (Dijkstra’s, A*, contraction hierarchies), map tile rendering and serving at multiple zoom levels, geocoding and reverse geocoding, real-time traffic data integration, ETAs with live traffic, turn-by-turn navigation, offline maps, and pre-computation strategies for routing.
22. Design a Collaborative Editing Service like Google Docs
Why this difficulty: Reported at Meta and Google. The real-time conflict resolution problem is genuinely hard.
Candidates must understand either Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs), both of which are research-level topics. This separates senior engineers from mid-level candidates.
Key concepts tested: Operational Transformation (OT) or CRDTs for conflict resolution, WebSocket connections for real-time sync, document versioning and history, cursor position sharing, permission models, offline editing with eventual sync, and rich text formatting consistency.
23. Design a Payment System like Stripe
Why this difficulty: Reported at Stripe, Amazon, PayPal, and Capital One. The combination of financial correctness requirements (money can never be lost or duplicated), external payment processor integration, and regulatory compliance makes this exceptionally challenging.
Key concepts tested: Idempotency for payment retries, double-entry bookkeeping/ledger design, payment state machine (pending → authorized → captured → settled), reconciliation processes, PCI DSS compliance, fraud detection integration, multi-currency support, and webhook-based async notification.
24. Design a Stock Exchange
Why this difficulty: Extreme latency requirements (microsecond-level for order matching) fundamentally change the architecture; no traditional database can serve the hot path.
Tests whether candidates can reason about ultra-low-latency systems.
Key concepts tested: Order matching engine (price-time priority), order book data structure (sorted by price level), market data distribution (multicast), low-latency architecture (kernel bypass, FPGA), risk checks, market orders vs. limit orders, and sequencer for deterministic replay.
25. Design a Distributed Message Queue like Kafka
Why this difficulty: While the pub/sub concept is simple (Question 10), designing the distributed infrastructure that guarantees durability, ordering, and exactly-once delivery across a cluster of brokers is a hard distributed systems problem.
Key concepts tested: Broker cluster management, partition replication with ISR (in-sync replicas), leader election for partitions, consumer group rebalancing, exactly-once delivery semantics, log compaction, message retention policies, and backpressure handling under load.
26. Design a Video Conferencing System like Zoom
Why this difficulty: Real-time audio/video with multiple participants creates strict latency constraints (<150ms end-to-end).
The architecture choice between SFU and MCU has profound implications for quality, cost, and scalability.
Key concepts tested: WebRTC protocol stack, Selective Forwarding Unit (SFU) vs. Multipoint Control Unit (MCU), adaptive bitrate for video, simulcast (sending multiple quality layers), screen sharing, SRTP for encryption, TURN/STUN for NAT traversal, recording and transcription, and handling network jitter.
27. Design S3-Like Object Storage
Why this difficulty: Designing storage that achieves 99.999999999% (11 nines) durability requires deep knowledge of erasure coding, data placement, and failure domains. This is pure distributed systems engineering.
Key concepts tested: Erasure coding for durability, data placement across failure domains (rack-aware, AZ-aware), metadata service design, consistent hashing for object distribution, garbage collection, versioning, lifecycle policies, and multipart upload for large objects.
28. Design a Food Delivery Service like DoorDash or Uber Eats
Why this difficulty: It’s a three-sided marketplace (customers, restaurants, drivers) with real-time coordination requirements, complex state machines, and multiple concurrent workflows.
More complex than Uber because of the restaurant preparation time variable.
Key concepts tested: Three-sided marketplace coordination, order state machine (placed → accepted → preparing → ready → picked up → delivered), dispatch and batching optimization, real-time driver tracking, restaurant integration and menu management, delivery time estimation (kitchen prep + transit), and surge/dynamic pricing.
29. Design a Code Deployment System
Why this difficulty: This question tests operational systems knowledge that many candidates lack; CI/CD pipelines, rollback strategies, and progressive delivery are not standard textbook topics.
Key concepts tested: Build service and artifact storage, canary deployments and progressive rollout, blue-green deployment strategy, rollback mechanisms, health checks and automated rollback triggers, dependency management, multi-region deployment coordination, and feature flags.
30. Design a Distributed Locking Service like Google’s Chubby
Why this difficulty: It requires understanding of consensus protocols (Paxos or Raft), which represent some of the most challenging concepts in distributed systems. Candidates must reason about split-brain scenarios, network partitions, and correctness under failure.
Key concepts tested: Paxos or Raft consensus protocol, leader election, lease-based locking with TTL, fencing tokens to prevent stale locks, session management with heartbeats, handling network partitions and split-brain, read vs. write quorums, and linearizable vs. sequential consistency.
How to Use This List Strategically
The difficulty tiers align with seniority expectations: beginner questions map to L3–L4 interviews, intermediate to L4–L5, and advanced to L5–L6+.
Three structural patterns emerge across all 30 questions.
First, every question tests trade-off reasoning.
There is no single correct answer, and interviewers evaluate how candidates navigate competing constraints (consistency vs. availability, latency vs. throughput, cost vs. reliability).
Second, questions increasingly test real-time system design: 18 of the 30 questions involve some form of real-time data flow (WebSockets, streaming, live updates).
Third, the modern trend is toward multi-service systems: questions like TikTok, DoorDash, and Uber require orchestrating 5–10 services simultaneously, which is why they appear at higher difficulty levels.
For preparation, candidates should master the beginner tier completely before moving to intermediate.
The infrastructure patterns from questions 1–10 (caching, rate limiting, message queues, consistent hashing) appear as components in nearly every intermediate and advanced question.
The most efficient study order is to work through these questions sequentially, as each tier builds on concepts from the previous one.