System Design Interview Questions Most Asked by FAANG Companies

System design interviews at FAANG companies are rarely about memorizing architectures. They’re about how you think: can you reason about scale, trade-offs, and ambiguity in real time? The most common system design interview questions look deceptively simple—“Design Twitter,” “Design a URL shortener”—but behind them is a consistent set of concepts and patterns.

This guide walks through the most asked FAANG system design interview questions, how they’re structured, and the core distributed systems concepts you’re expected to demonstrate. The focus is educational: what you need to know, how to reason, and how to practice.

---

How FAANG System Design Interviews Are Structured

Most FAANG system design interviews follow a similar pattern:

1. Open-ended prompt
   Examples:

   • “Design a URL shortener like bit.ly.”
   • “Design Instagram.”
   • “Design a news feed system.”
   • “Design a distributed cache.”

2. Clarification & requirements

   • Functional requirements (what the system must do).
   • Non-functional requirements (scale, latency, availability, consistency).
   • Constraints (traffic, data size, QPS, latency SLAs).

3. High-level architecture

   • Core components and how they interact.
   • Data model, APIs, and external dependencies.

4. Deep dives

   • Storage, indexing, caching, sharding, replication, consistency.
   • Bottlenecks and failure scenarios.
   • Trade-offs between design options.

5. Wrap-up

   • Scaling strategies.
   • Future extensions.
   • Operational concerns (monitoring, backfills, migrations).

Strong candidates don’t jump into drawing boxes. They start by clarifying the problem, then iteratively refine the design as new constraints surface.

---

Core Themes Behind Common System Design Interview Questions

Before we dive into specific FAANG system design questions, it’s useful to see the patterns they test:

• Data modeling & APIs
• Read-heavy vs write-heavy workloads
• Consistency vs availability trade-offs
• Partitioning and sharding
• Caching strategies
• Indexing and search
• Event-driven and streaming systems
• Rate limiting, backpressure, and throttling
• Fault tolerance and replication
• Observability (logging, metrics, tracing)

Most “design X” questions are thin wrappers around these fundamentals.

---

1. Design a URL Shortener (bit.ly / tinyurl)

This is one of the most common system design interview questions because it’s constrained but touches many core ideas.

Clarify Requirements

Typical requirements you should clarify:

• Functional

  • Given a long URL, generate a short URL.
  • Redirect short URL → original long URL.
  • Support custom aliases (optional).
  • Track basic analytics (click count, timestamp, referrer) (optional).

• Non-functional

  • High read traffic (redirects) vs moderate write traffic (creations).
  • Low latency redirects (< 50–100 ms).
  • High availability; eventual consistency is acceptable for analytics.
  • Scale: e.g., 100M URLs, 1B redirects/day.

High-Level Design

Core components:

• API service
  • POST /shorten → returns short URL.
  • GET /{shortCode} → redirects to long URL.
• Application service
  • Business logic: generate codes, validate URLs, handle collisions.
• Data store
  • Mapping: shortCode → longURL (+ metadata).
• Cache
  • For hot short codes to reduce database reads.
• Analytics pipeline (optional)
  • Stream clicks to a log or queue, aggregate asynchronously.

Key Design Decisions

1. Short Code Generation

• Approach A: Hash-based
  • Hash the long URL (e.g., SHA-256), then base62-encode and truncate.
  • Handle collisions with rehashing or random salt.
• Approach B: ID-based
  • Use an auto-incrementing ID, then base62-encode.
  • Requires ID generator (DB sequence, Snowflake-like service).

Trade-offs:

• Hash-based: deterministic, no DB lookup to check existing URL (if you accept duplicates).
• ID-based: simple, but central ID generator can be a bottleneck.

2. Storage

• Simple key-value mapping:
  • Key: shortCode (string, indexed).
  • Value: longURL, createdAt, ownerId, etc.
• For scale:
  • Use a distributed key-value store (e.g., DynamoDB, Cassandra, or sharded SQL).

3. Caching Strategy

• Read-heavy: most traffic is redirects.
• Cache entries: shortCode → longURL.
• Use:
  • Write-through or lazy loading.
  • TTL based on usage patterns.

4. Analytics

• On each redirect:
  • Don’t write directly to DB synchronously (too slow).
  • Instead:
    • Publish an event to a message queue (e.g., Kafka).
    • Downstream consumers aggregate counts into a separate store.

---

---

2. Design Twitter / News Feed (Timeline Service)

“Design Twitter” or “Design a news feed” is a classic FAANG system design interview question. It tests your understanding of fan-out vs fan-in, caching, and storage patterns.

Clarify Requirements

• Functional

  • Users can post tweets.
  • Users follow other users.
  • Users see a home timeline (tweets from people they follow).
  • Optional: likes, retweets, replies.

• Non-functional

  • Read-heavy: timelines are read much more than tweets are written.
  • Latency: timeline fetch < 200 ms.
  • Scale: 100M+ users, millions of DAUs, heavy skew (some users have millions of followers).

Core Components

• User service: profiles, follow graph.
• Tweet service: create/read tweets.
• Timeline service: generate and serve home timelines.
• Social graph store: followers/following relationships.
• Caches: user timelines, user profiles.
• Search / indexing: for hashtags, full-text search (optional).

Timeline Generation: Fan-out vs Fan-in

This is the key design axis.

1. Fan-out on write

• When a user posts a tweet:
  • Push the tweet ID to the home timeline of each follower.
• Retrieval:
  • Reading a home timeline is a simple read from a per-user list.

Pros:

• Fast reads (simple list fetch).
• Can use caching effectively.

Cons:

• Expensive writes for users with many followers (celebrity accounts).
• Potentially millions of writes per tweet.

Mitigation:

• Hybrid approach:
  • Fan-out to “normal” users.
  • For celebrity accounts, compute timelines on read (fan-in).

2. Fan-in on read

• Store tweets in a global or per-user timeline.
• On read:
  • Fetch latest tweet IDs from all followees.
  • Merge-sort them by timestamp.

Pros:

• Cheap writes.
• No write amplification.

Cons:

• Expensive reads (N-way merge).
• Hard to meet low-latency SLAs at scale.

Most production systems use a hybrid model.

Storage & Caching

• Tweet storage
  • Append-only store (e.g., sharded SQL, NoSQL).
  • Indexed by tweetId, userId, createdAt.
• Timeline storage
  • Per-user list of tweet IDs (e.g., in Redis, Cassandra).
• Caching
  • Cache home timelines for active users.
  • Use LRU or custom eviction.

Additional Concerns

• Out-of-order delivery: eventual consistency between posting and timeline updates.
• Backpressure: when a celebrity posts, avoid overloading fan-out workers.
• Pagination: support infinite scroll via max_id or cursor.

---

3. Design Instagram / Photo Sharing Service

“Design Instagram” or “Design a photo sharing system” builds on the news feed question and adds large object storage and CDNs.

Requirements

• Users upload photos (and possibly videos).
• Users follow others and see a feed of photos.
• Photos must load quickly globally.
• Scale: petabytes of media, millions of daily uploads.

Key Components

• Upload service
  • Handles file uploads, authentication, metadata validation.
• Media storage
  • Store photos in an object store (e.g., S3, GCS).
  • Generate multiple resolutions (thumbnails, medium, original).
• CDN
  • Serve media from edge locations.
• Metadata store
  • Photo metadata: photoId, userId, URLs to different resolutions, captions, tags.
• Feed service
  • Similar to Twitter’s timeline service.

Data Flow

1. Client uploads a photo to upload endpoint (or directly to object store with signed URL).
2. Upload service stores metadata and triggers an asynchronous processing job:
   • Image resizing.
   • Validation, EXIF stripping, etc.
3. Processed images are stored in object store; URLs are updated in metadata.
4. Feed generation uses metadata to render timelines.

Key design points:

• Use CDNs to reduce latency.
• Asynchronous processing to keep upload latency acceptable.
• Idempotent processing for retries.

---

---

4. Design a Distributed Cache

“Design a distributed cache” or “Design Redis-like system” is a frequent architecture interview question that tests consistency, partitioning, and replication.

Requirements

• In-memory key-value store.
• Low latency (sub-millisecond) for gets/sets.
• High availability; tolerate node failures.
• Horizontal scalability.

Core Topics to Cover

1. Data Partitioning

• Consistent hashing
  • Map keys to hash ring.
  • Place nodes on the ring; each node owns a range.
  • When nodes join/leave, only a small fraction of keys move.

2. Replication

• Leader–follower (primary–replica)
  • Each partition has a leader and one or more followers.
  • Writes go to leader; followers replicate asynchronously or semi-synchronously.
• Trade-off:
  • Synchronous replication: stronger consistency, higher latency.
  • Asynchronous: better performance, risk of data loss on leader failure.

3. Cache Invalidation & Coherence

• If used as a read-through cache:
  • On cache miss, fetch from DB and populate cache.
• Invalidation strategies:
  • Write-through: write to cache and DB in same flow.
  • Write-behind: write to cache, asynchronously persist to DB.
  • Cache-aside: application explicitly manages cache set/delete.

4. Eviction Policies

• LRU, LFU, FIFO, or custom policies.
• TTLs per key for time-based expiration.

---

5. Design an API Rate Limiter

Rate limiting is a staple FAANG system design interview question because it’s small but rich in trade-offs.

Requirements

• Limit requests per user / API key / IP.
• Enforcement:
  • E.g., 100 requests per minute.
• Distributed deployment (multiple API servers).

Algorithms to Discuss

• Token bucket
  • Tokens added at fixed rate up to a max bucket size.
  • Each request consumes a token; if empty, reject.
• Leaky bucket
  • Queue with fixed drain rate.
• Fixed window counter
  • Simple but suffers from boundary issues.
• Sliding window log / sliding window counter
  • More accurate but more storage/compute.

Distributed Implementation

• Centralized store (e.g., Redis) with atomic operations:
  • Use INCR with TTL for counters.
  • Use Lua scripts or transactions for atomicity.
• Or local plus global:
  • Local counters with periodic sync to a central store.

Key points:

• Atomicity is crucial to avoid over-allowing.
• Low latency: rate limiting must not dominate request time.

---

6. Design a Web Crawler

“Design a web crawler” tests distributed coordination, politeness, and storage.

Requirements

• Crawl web pages starting from seed URLs.
• Respect robots.txt and per-domain rate limits.
• Avoid infinite loops and duplicate content.
• Store fetched pages and metadata.

Key Components

• URL frontier
  • Queue or priority queue of URLs to crawl.
• Fetcher workers
  • Fetch pages, parse links.
• URL deduplication
  • Ensure each URL is crawled at most once.
• Content storage
  • Raw HTML, extracted text, metadata.
• Politeness manager
  • Rate limiting per domain.

Design points:

• Use distributed queues for frontier.
• Maintain a visited set (e.g., Bloom filters plus persistent store).
• Shard by hostname or hash of URL.

---

7. Design a Search Autocomplete / Typeahead

Autocomplete is a common architecture interview question focusing on indexing, prefix search, and caching.

Requirements

• As the user types, suggest top K completions.
• Suggestions based on:
  • Prefix match.
  • Popularity (frequency of queries).
• Latency: < 100 ms per request.

Approaches

• Trie-based index
  • Each node stores top K completions for that prefix.
  • Memory heavy but very fast.
• Inverted index + prefix search
  • Use search engine (e.g., Elasticsearch) with edge n-grams.
• Hybrid
  • Precompute suggestions for popular prefixes; fallback to search for rare ones.

Other considerations:

• Language and locale support.
• Incremental updates (new queries affecting popularity).
• Cache hot prefixes in memory.

---

8. Design a Messaging System (Chat / WhatsApp)

Designing messaging systems tests ordering, delivery guarantees, and storage.

Requirements

• 1:1 and group chats.
• Message ordering per conversation.
• Online/offline delivery.
• Read receipts (optional).
• Scale: millions of concurrent users.

High-Level Design

• Gateway / WebSocket service
  • Maintains persistent connections to clients.
• Message routing service
  • Routes messages to appropriate user or group.
• Message store
  • Durable storage for messages (per-conversation log).
• Notification service
  • Push notifications for offline users.

Key discussion points:

• Delivery semantics
  • At least once vs at most once vs exactly-once (usually at least once with idempotent clients).
• Ordering
  • Use per-conversation sequence numbers or timestamps with tie-breaking.
• Online presence
  • Track user status with heartbeats and timeouts.

---

9. Design a Ride-Sharing System (Uber / Lyft)

This question combines geospatial indexing, matching algorithms, and real-time updates.

Requirements

• Riders request rides.
• Drivers broadcast their location.
• System matches riders to nearby drivers.
• Scale: millions of trips/day.

Core Components

• Location service
  • Ingests frequent GPS updates from drivers.
• Geospatial index
  • Index drivers by location (e.g., geohash, quad-trees).
• Matching service
  • Given a rider’s location, find candidate drivers.
  • Apply pricing, ETA, and other constraints.
• Trip service
  • Manages lifecycle of a trip.

Key topics:

• Geohashing to map lat/long to a grid.
• Hotspot handling in dense urban areas.
• Event-driven updates to clients (WebSockets, SSE).

---

Common Pitfalls in System Design Interviews

Even strong engineers often stumble on predictable issues in FAANG system design interviews.

1. Jumping into Solutions Without Requirements

• Mistake:
  • Drawing Kafka, Redis, and five microservices before clarifying what’s needed.
• Fix:
  • Spend the first 3–5 minutes clarifying:
    • Functional scope.
    • Scale assumptions.
    • Latency and availability requirements.

2. Ignoring Scale and Numbers

• Mistake:
  • Saying “we’ll store everything in a database” without estimating data size or QPS.
• Fix:
  • Use back-of-the-envelope calculations:
    • Requests per second.
    • Data per day.
    • Storage requirements over 1–3 years.

3. Over-Focusing on One Layer

• Mistake:
  • Spending 25 minutes on schema design and ignoring caching, partitioning, and failures.
• Fix:
  • Start with end-to-end architecture, then choose 1–2 areas to deep dive:
    • Data model + partitioning.
    • Caching + consistency.
    • Failure handling + replication.

4. Not Addressing Failures and Trade-offs

• Mistake:
  • Assuming every component is always up and consistent.
• Fix:
  • Discuss:
    • What happens if a node or region fails?
    • How do we recover from partial writes?
    • CAP trade-offs (where do we choose availability vs consistency?).

5. Being Too Vague

• Mistake:
  • Saying “we’ll scale horizontally” without explaining how.
• Fix:
  • Be concrete:
    • “We’ll shard users by userId hash modulo N.”
    • “We’ll use consistent hashing on key to distribute cache entries.”

---

Best Practices for Answering System Design Interview Questions

1. Use a Structured Framework

One common pattern:

1. Clarify requirements.
2. Define APIs and data model.
3. Propose high-level architecture.
4. Discuss scaling strategies.
5. Handle failures and consistency.
6. Talk about trade-offs and extensions.

This structure works for most FAANG system design and distributed systems interviews.

2. Anchor Your Design with Numbers

Example for a URL shortener:

• 1B redirects/day ≈ ~11.6K requests/sec average.
• Peak QPS might be 5–10x average: plan for 100–150K QPS.
• If each entry is ~200 bytes and we store 1B URLs:
  • 200 GB of raw data (plus replication and indexes).

This helps justify:

• Why you need sharding.
• Why you need caching.
• What hardware or cloud resources might be required.

3. Talk About Trade-offs Explicitly

Interviewers want to see you reason:

• “We could use a global secondary index here, but that makes writes more expensive. Since writes are only 10% of traffic and we need flexible reads, that’s acceptable.”
• “Using synchronous replication gives us stronger consistency but may hurt latency; for this user-facing workload, I’d choose async replication with clear failure semantics.”

4. Design for Evolution, Not Perfection

You don’t need a “production-ready” design in 45 minutes. Show how the system can evolve:

• “We’ll start with a single-region deployment; as traffic grows, we can move to multi-region with active-active replication and conflict resolution.”
• “Initially we can compute feeds on read; when we hit scale, we’ll introduce a fan-out-on-write service.”

5. Practice With Realistic Feedback

Practicing end-to-end designs and getting targeted feedback is crucial. Pattern-based practice—similar to how you’d approach DSA patterns—helps you recognize that many questions are variations of a few core architectures.

If you want AI-driven practice that simulates real interviews and provides structured feedback on your reasoning, you can explore the mock interview flows at /ai-interview.

---

Example: A Reusable Checklist for Any System Design Question

Use this as a quick mental model during interviews:

1. Requirements
   • Functional, non-functional, scale assumptions.
2. API & Data Model
   • Core entities and relationships.
3. High-Level Architecture
   • Services, storage, communication patterns.
4. Data Flow
   • Read/write paths, background jobs.
5. Storage & Indexing
   • Data stores, partitioning, indexing.
6. Caching
   • What to cache, where, and invalidation strategy.
7. Scaling
   • Horizontal vs vertical, sharding, load balancing.
8. Reliability & Consistency
   • Replication, failover, CAP decisions.
9. Security & Multi-tenancy (if relevant)
   • Auth, rate limiting, isolation.
10. Observability
    • Logs, metrics, tracing, alerting.

---

---

Key Takeaways

• Most FAANG system design interview questions—URL shortener, Twitter, Instagram, distributed cache, rate limiter, web crawler, autocomplete, messaging, ride-sharing—are different skins over the same core distributed systems concepts.
• Interviewers look for:
  • Clear requirements gathering.
  • Sensible high-level architecture.
  • Ability to reason about scale, consistency, and failures.
  • Explicit discussion of trade-offs.
• Use a structured approach and anchor your decisions with simple estimates.
• Practice recognizing patterns: feed systems, key-value stores, search, streaming, geospatial, etc. Over time, new questions will feel like combinations of familiar building blocks.

With deliberate practice on these canonical architectures and a consistent framework, FAANG system design and architecture interview questions become less about recall and more about applying well-understood patterns to new contexts.