Complex Systems · Phase 4: High-Level Design (HLD)
Social Timeline & Newsfeed (Twitter/X & Meta Feed)
Architect a planetary newsfeed supporting 500M DAU: Fanout-on-Write (push for normal users) vs Fanout-on-Read (pull for celebrities), hybrid fanout engines, and Redis timeline lists.
Primary specification: Timelines at Scale (Twitter Engineering)
Lesson 27 of 33
1d streakThe Architectural Question
When a celebrity with 80M followers posts, a naive fanout-on-write pushes 80 million timeline updates, creating a multi-minute queue backlog that delays messages globally.
Core Engineering Objectives
- Fanout-on-Write (Push model): fast reads, but high write amplification for celebrity accounts
- Fanout-on-Read (Pull model): zero write amplification, but expensive query-time aggregation
- The Hybrid Fanout Engine: push for normal users (<5,000 followers) and pull dynamically for celebrities
Topic sizing snapshot
The four numbers that materially affect this architecture. Use them as bounds, not as a generic calculator embedded in every lesson.
Peak QPS
70,000 Feed Read RPS / 12,000 Tweet Write RPS
5-Yr Storage
180 TB tweet metadata & text over 5 years
Bandwidth
15 Gbps feed egress bandwidth
Working Set RAM
400 GB Redis cluster caching 800-tweet timelines for 50M daily active users
Architectural Trade-Off Analysis
Compare latency, throughput, consistency, and operational complexity across core industry alternatives.
Architecture Decision Matrix
Multi-axis engineering evaluation and FAANG interview rules of thumb.
SQL (Postgres / MySQL)
Relational ACID Store
Structured schema, relational joins, ACID transactions, and strict foreign keys.
NoSQL (Cassandra / DynamoDB)
Distributed Non-Relational Store
Horizontal partition keys, denormalized documents/wide-columns, and tunable consistency.
| Evaluation Axis | SQL (Postgres / MySQL) | NoSQL (Cassandra / DynamoDB) | Details |
|---|---|---|---|
Latency | Moderate | Strong | |
Throughput | Moderate | Strong | |
Scalability | Moderate | Strong | |
Consistency | Strong | Moderate | |
Complexity | Strong | Moderate | |
Cost | Moderate | Strong |
When to Choose in an Architecture Interview
Choose SQL when ACID guarantees are non-negotiable (financial ledgers, payment processing, inventory checkout) or when query access patterns are unpredictable and require ad-hoc analytical joins.
Choose NoSQL when write volume exceeds single-node capacity (>20K writes/sec), data is unstructured/hierarchical (logs, telemetry, user feeds), or multi-region active-active replication is mandatory.
Never say "NoSQL is faster than SQL" without qualification. SQL with proper B-Tree indexes on indexed primary keys is lightning fast. NoSQL wins on horizontal write scaling, not inherent single-row read speed.
Production Postmortem & Verification
Production Incident Postmortem
- Trigger / Setup: A platform uses pure Fanout-on-Write; a soccer star with 90M followers posts a goal celebration.
- Production Symptom: Message queues back up with 90 million write tasks; message delivery for all other users is delayed by 45 minutes.
- Root Cause & Fix: Use a hybrid fanout model; do not fan out celebrity posts to follower timelines. Merge celebrity posts dynamically at read time.
Acceptance Criteria & Outcomes
- Quantify write amplification math for push vs pull across normal and celebrity follower distributions.
- Design Redis timeline data structures (ZSET with timestamp as score, capped at 800 items).
- Implement cursor-based pagination to eliminate duplicate items across shifting feed timelines.
End-of-Chapter Synthesis & Key Takeaway
Social Timeline & Newsfeed (Twitter/X & Meta Feed) is built around one fundamental rule: Establish clear responsibility and explicit trade-offs.. Before adding components, establish explicit quantitative SLAs for latency, throughput, and consistency. Choose the simplest architecture that meets stated constraints.
Architectural & Technical Interview Review
Core FAANG Interview Questions
Q01How do you justify introducing Social Timeline & Newsfeed (Twitter/X & Meta Feed) into a high-scale production architecture?Click to reveal model answer →Hide answer ↑Requirements & Design Brief
Introduce Social Timeline & Newsfeed (Twitter/X & Meta Feed) only when measured scale, data size, or failure boundaries exceed single-node capacity. State the exact bottleneck, evaluate operational overhead, and verify that the trade-offs justify the added moving parts.
Q02What is the primary trade-off and hidden operational cost of Social Timeline & Newsfeed (Twitter/X & Meta Feed)?Click to reveal model answer →Hide answer ↑Architecture Trade-offs
It improves scalability and availability, but introduces network hops, serialization overhead, and eventual consistency or coordination complexity.
Q03How do you handle catastrophic failure or dependency degradation in Social Timeline & Newsfeed (Twitter/X & Meta Feed)?Click to reveal model answer →Hide answer ↑Failure Review & Recovery
Implement connect/read timeouts, exponential backoff with jitter, and fallback defaults so downstream degradations do not cause cascading outages.
Production Pitfalls & Anti-Patterns
Critical Failure Anti-Patterns
Premature Distributed Complexity
Scattering distributed components before identifying concrete write, read, or storage limits creates accidental points of failure and operational debt.
Production Mitigation: Start with the simplest modular design that satisfies requirements, evolving it only as measured constraints dictate.
Unbounded Retries and Cascading Storms
When a dependency degrades, immediate synchronized retries multiply downstream traffic, turning a minor slowdown into a total fleet outage.
Production Mitigation: Enforce strict retry budgets, exponential backoff, and full randomized jitter on all client calls.
Neglecting Observability and Metrics
Deploying architecture without distributed tracing or p99 tail latency alerts leaves engineers blind when partial partitions occur.
Production Mitigation: Export metrics for request rate, error rate, p95/p99 duration, and saturation at every service boundary.
Step 1: Problem Statement & Operational Context
1. Author
Publishes one canonical post.
2. Event log
Buffers fan-out work and supports replay.
3. Fan-out workers
Push normal-author post IDs into follower inboxes.
4. Feed service
Pulls celebrity posts and merges ranked candidates.
5. Reader
Receives a cursor-based page of hydrated posts.
Store post IDs in inboxes; hydrate current post data after ranking so edits and deletions remain manageable.
A planetary social newsfeed engine aggregates, ranks, and delivers personalized streams of content to hundreds of millions of daily active users (DAU). Every time a user opens their application, the feed must assemble a chronological or algorithmically curated sequence of recent posts authored by accounts they follow, complete with media attachments, reply counts, and engagement metrics.
The Core Asymmetric Fanout Dilemma
Fanout-on-Write (Push Model)
When an author posts, a background worker proactively inserts the post ID into the pre-computed home timeline cache of every single follower. Reads are blazing fast (O(1)), but writes suffer massive amplification.
Fanout-on-Read (Pull Model)
When a user opens their timeline, the system dynamically queries the latest posts of everyone they follow and merges them in real time. Writes are O(1), but reads suffer severe computational and network fanout.
Hybrid Fanout Engine
The production standard (used by Twitter/X): push fanout is applied to normal users (<25,000 followers), while celebrity accounts bypass push fanout entirely and are merged dynamically at read time.