Bird
Raised Fist0

Design Twitter - Tweets, Follow Graph, Timeline Generation at Scale

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design Twitter - Tweets, Follow Graph, Timeline Generation at Scale
45 min · senior
senior

Design a Twitter-like system supporting 50 million daily active users (DAU) with a focus on tweet ingestion, follow graph management, and timeline generation. The system must handle high write and read throughput, maintain low latency for timeline delivery, and ensure data privacy with encryption at rest and in transit.

Constraints
  • Support 50M DAU with peak write throughput of ~1M tweets/sec
  • Timeline generation P99 latency under 200ms
  • Follow graph updates must propagate within 1 minute
  • End-to-end encryption for tweets and user data
  • Offline timeline delivery for users with intermittent connectivity
📋
Guided Steps
1/5
Step 1
Tweet Ingestion and Storage
How would you design the tweet ingestion pipeline to handle 1M tweets/sec with durability and ordering guarantees?
💡 Hint
Consider partitioning strategies and write-optimized storage systems that support high throughput and range queries.
Key Decision
Use Apache Kafka with tweet_id as partition key to ensure ordered ingestion per tweet stream, and Cassandra with partition_key=user_id for durable, scalable storage supporting fast writes and range scans for timeline generation.
Interviewer Expectation
Mid-level: Names Kafka and Cassandra for ingestion and storage. Senior: Explains why tweet_id or user_id as partition key ensures ordering and locality, and why relational DBs like MySQL fail at this scale due to write bottlenecks.
⚠️Common Wrong Answer
Using a relational database like MySQL for tweet writes leads to write contention and poor horizontal scalability at 1M writes/sec.
Step 2
Follow Graph Management
How would you design the follow/unfollow system to support 50M users and propagate changes within 1 minute?
💡 Hint
Think about graph storage optimized for reads and writes, and asynchronous propagation mechanisms for timeline updates.
Key Decision
Use a distributed graph database like Neo4j or a wide-column store like Cassandra with user_id as partition key to store follow edges, combined with Kafka topics for follow event propagation to timeline generators asynchronously.
Interviewer Expectation
Mid-level: Identifies graph DB or Cassandra for follow graph storage. Senior: Explains trade-offs between graph DB consistency and Cassandra’s write scalability, and why synchronous updates would increase latency and reduce availability.
⚠️Common Wrong Answer
Synchronous updates to all followers’ timelines on follow/unfollow cause high write amplification and latency spikes.
Step 3
Timeline Generation Strategy
How would you generate user timelines to meet P99 latency < 200ms and support offline delivery?
💡 Hint
Consider fan-out on write vs fan-out on read trade-offs and caching layers for fast timeline retrieval.
Key Decision
Implement hybrid fan-out: fan-out on write for users with <10K followers using Kafka streams and Cassandra for timeline storage, and fan-out on read with Redis caching for users with large follower counts, enabling low-latency timeline retrieval and offline delivery via persisted timeline shards.
Interviewer Expectation
Mid-level: Describes fan-out on write or read. Senior: Explains hybrid approach to balance write amplification and read latency, and how Redis TTL and Cassandra TTL support offline delivery and cache invalidation.
⚠️Common Wrong Answer
Pure fan-out on write causes write amplification and storage bloat for celebrities with millions of followers.
Step 4
Data Encryption and Security
How would you ensure end-to-end encryption for tweets and user data at rest and in transit without compromising performance?
💡 Hint
Think about encryption key management, TLS for transport, and encryption at storage layer with minimal latency impact.
Key Decision
Use TLS 1.3 for all client-server and inter-service communication, and encrypt tweets at rest using AWS KMS-managed envelope encryption integrated with Cassandra’s transparent data encryption (TDE), ensuring minimal latency overhead and compliance.
Interviewer Expectation
Mid-level: Mentions TLS and encryption at rest. Senior: Details envelope encryption, key rotation policies, and how encryption integrates with Cassandra without impacting write/read latency significantly.
⚠️Common Wrong Answer
Encrypting tweets at application layer without key management leads to key leakage risks and performance bottlenecks.
Step 5
API Design for Core Operations
Sketch the API design for posting a tweet, following/unfollowing a user, and retrieving a timeline with pagination.
💡 Hint
Consider RESTful endpoints, request/response payloads, and how to handle pagination and acknowledgments.
Key Decision
POST /tweets with JSON body including user_id and content; POST /follow with follower_id and followee_id; GET /timeline with user_id, cursor, and limit parameters supporting cursor-based pagination and HTTP 200 with timeline items and next_cursor.
Interviewer Expectation
Mid-level: Defines basic REST endpoints. Senior: Explains cursor-based pagination to avoid offset pitfalls, idempotency considerations for follow/unfollow, and how timeline retrieval supports offline sync.
⚠️Common Wrong Answer
Using offset-based pagination leads to inconsistent timeline views under concurrent writes.
🔌
API Design Challenge
Sketch 3 core API endpoints for the system: tweet posting, follow/unfollow, and timeline retrieval.
Hints
  • How does the client send a new tweet and ensure durability?
  • How does the system update the follow graph and propagate changes?
  • How does the client retrieve and paginate the timeline efficiently?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use Kafka with appropriate partition keys for ordered, scalable tweet ingestion.
  • Use Cassandra with user_id partition key for durable, scalable tweet and follow graph storage.
  • Explain fan-out on write vs fan-out on read trade-offs and propose hybrid timeline generation.
  • Design APIs with cursor-based pagination and idempotency for follow/unfollow.
  • Include encryption at rest and in transit with key management.
Good to Have - 30%
  • Discuss offline timeline delivery using Redis TTL and persisted timeline shards.
  • Explain asynchronous propagation of follow graph changes via Kafka event streams.
  • Describe key rotation and envelope encryption integration with storage layer.
Bonus - 10%
    Anti-patterns to Avoid
    ✅
    Model Answer
    ▼ Reveal

    This design addresses the challenges of scaling Twitter-like tweet ingestion, follow graph management, and timeline generation for 50M DAU with low latency and strong data consistency. It uses proven distributed technologies and encryption to meet throughput, latency, and security constraints.

    Key Decisions
    • Use Apache Kafka with tweet_id as partition key to ensure ordered ingestion and scalability at 1M writes/sec.
    • Store tweets and follow edges in Cassandra with user_id partition key to enable fast writes and efficient range scans.
    • Implement asynchronous follow graph updates via Kafka topics to avoid latency spikes and write amplification.
    • Adopt hybrid fan-out timeline generation to balance write amplification and read latency, using Kafka streams, Cassandra, and Redis caching with TTL.
    • Encrypt all data in transit using TLS 1.3 and at rest using AWS KMS envelope encryption integrated with Cassandra's TDE to minimize latency impact.
    • Design APIs with cursor-based pagination to avoid offset-based pitfalls and ensure consistent timeline retrieval under concurrent writes.
    • Use idempotent follow/unfollow APIs to handle retries safely.
    • Support offline timeline delivery via Redis caching with TTL and persisted timeline shards.
    • Apache Kafka with tweet_id partition key ensures ordered, scalable ingestion of tweets at 1M writes/sec.
    • Cassandra with user_id partition key supports high write throughput and efficient range scans for timeline generation.
    • Distributed graph storage (Neo4j or Cassandra) combined with Kafka event streams enables scalable follow graph management with asynchronous propagation.
    • Hybrid fan-out timeline generation balances write amplification and read latency, using Kafka streams, Cassandra, and Redis caching.
    • TLS 1.3 for transport encryption and AWS KMS envelope encryption integrated with Cassandra TDE ensures secure data at rest and in transit.
    • Cursor-based pagination in timeline API avoids offset pitfalls and supports consistent, low-latency timeline retrieval.
    • Redis caching with TTL and heartbeat mechanisms supports offline timeline delivery and efficient cache invalidation.
    • Kafka partitioning strategy aligns with user or tweet IDs to maintain ordering and locality, avoiding cross-partition coordination overhead.

    Practice

    (1/5)
    1. A webhook delivery system must guarantee ordered delivery of events per subscriber, even under retries and failures. Which component is best suited to enforce per-subscriber ordering?
    easy
    A. A partitioned message queue like Kafka keyed by subscriber ID
    B. A distributed cache like Redis to store last delivered event per subscriber
    C. A relational database with a global sequence number column
    D. A load balancer that routes events to the same delivery worker

    Solution

    1. Step 1: Identify ordering guarantee mechanism

      Kafka partitions keyed by subscriber ID ensure all events for that subscriber go to the same partition, preserving order.

    2. Step 2: Eliminate other options

      Redis cache lacks strong ordering guarantees under retries; relational DB global sequence causes contention and latency; load balancer routing alone doesn't guarantee ordering without stateful processing.

    3. Final Answer:

      Option A -> Option A

    4. Quick Check:

      Kafka partition key -> per-subscriber ordering guaranteed [check]
    Hint: Partition by subscriber ID for ordering [check]
    Common Mistakes:
    2. If the idempotency key store becomes unavailable, what is the most likely failure mode for the payment API when a client retries a payment request?
    medium
    A. The payment API processes each retry as a new payment, causing duplicate charges
    B. The payment API queues requests until the store recovers, delaying all payments
    C. The payment API rejects all requests with 503 Service Unavailable errors
    D. The payment API returns cached responses from a fallback in-memory store

    Solution

    1. Step 1: Understand idempotency store role in retries

      Without the store, the API cannot verify if a request is a retry, so it must delay processing to avoid duplicates.

    2. Step 2: Eliminate other options

      Rejecting all requests is possible but not typical; processing retries as new causes duplicates, which is avoided; fallback caches are uncommon and inconsistent.

    3. Final Answer:

      Option B -> Option B

    4. Quick Check:

      Unavailable idempotency store causes request queuing to prevent duplicates [check]
    Hint: No idempotency store -> queue retries to avoid duplicates [check]
    Common Mistakes:
    3. If the CDN's cache invalidation mechanism fails to propagate updates, what is the exact failure experienced by end users?
    medium
    A. Users get 404 errors because the CDN deletes cached content prematurely
    B. Users receive outdated content until cache TTL expires, causing stale data display
    C. Origin servers become overloaded as CDN stops serving any cached content
    D. Users experience increased latency due to CDN routing loops

    Solution

    1. Step 1: Understand cache invalidation failure impact

      Failure to propagate invalidation means cached content remains stale beyond intended update.

    2. Step 2: Identify user experience as stale content served until TTL expiry

      Users see outdated data until cache naturally expires or is manually cleared.

    3. Final Answer:

      Option B -> Option B

    4. Quick Check:

      Cache invalidation failure -> stale content served, not errors or overload [check]
    Hint: Invalidation fails -> stale content served until TTL expires [OK]
    Common Mistakes:
    4. At 10x traffic scale during a flash sale, which component is most likely to fail first and why?
    hard
    A. The relational database because it cannot handle 10x write throughput without sharding
    B. The API Gateway because it maintains stateful user sessions and cannot horizontally scale easily
    C. The cache layer because TTL expiration floods the database with cache misses
    D. The inventory service because distributed locking causes contention and latency spikes

    Solution

    1. Step 1: Identify stateful components under load

      API Gateway maintains user session state (e.g., WebSocket connections), which are sticky and stateful, limiting horizontal scaling.

    2. Step 2: Compare other components

      Relational DB (A) can be sharded; cache (C) TTL floods are mitigated by pre-warming; inventory locking (D) is optimized with partitioning. API Gateway statefulness causes connection limits and bottlenecks first.

    3. Final Answer:

      Option B -> Option B

    4. Quick Check:

      API Gateway stateful sessions limit horizontal scaling [check]
    Hint: Stateful API Gateway limits scaling under 10x load [check]
    Common Mistakes:
    5. At 10x scale, which component is most likely to become the bottleneck first when handling millions of concurrent video streams and progress updates, and why?
    hard
    A. The relational database storing user progress, due to write contention on user records
    B. The WebSocket servers maintaining live connections, due to stateful connection limits
    C. The Progress Worker service, due to single-threaded processing of progress update events
    D. The CDN edge servers, due to bandwidth limits serving video content globally

    Solution

    1. Step 1: Analyze stateful connection scaling

      WebSocket servers maintain stateful connections per user, limiting horizontal scaling due to connection affinity.

    2. Step 2: Compare other components' scalability

      Relational DB (The relational database storing user progress, due to write contention on user records) can be sharded; CDN (The CDN edge servers, due to bandwidth limits serving video content globally) scales horizontally; Progress Worker (The Progress Worker service, due to single-threaded processing of progress update events) can be parallelized.

    3. Final Answer:

      Option B -> Option B

    4. Quick Check:

      WebSocket servers hit stateful connection limits first [check]
    Hint: Stateful WebSocket servers limit scaling first [OK]
    Common Mistakes:
    Recommended

    Ready to prove it?

    Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

    10 questions~5 mineasy hard