Design a social feed like X / Twitter

Requirements

Say these out loud before drawing a single box. Interviewers score this.

Back-of-the-envelope math

X-scale, circa 2020. Assumptions labeled — interviewers care that you state them.

Architecture

The centerpiece. Write path fans out; read path merges.

flowchart LR
    C[Mobile / Web client] --> G[API Gateway]
    G --> PS[Post Service]
    G --> TS[Timeline Service]
    PS --> PDB[(Post Store
Postgres / Cassandra)]
    PS --> M[Media Service]
    M --> BS[(Blob Store
S3 + CDN)]
    PS --> K[Fan-out Queue
Kafka]
    K --> FW[Fan-out Workers]
    FW --> GR[(Follow Graph
Postgres)]
    FW -->|normal user| RC[(Timeline Cache
Redis Cluster
sorted set per user)]
    FW -->|celebrity| CI[(Celebrity Index
recent posts of top ~10K accounts)]
    TS --> RC
    TS --> CI
    TS --> PDB
    TS --> C

Two write paths, one read path. A post from a normal user is fanned out by workers into each follower's Redis sorted set (timeline:{user_id}, score = timestamp). A post from a celebrity skips the fan-out entirely and lands in the Celebrity Index. At read time the Timeline Service pulls the precomputed timeline and recent posts from followed celebrities, merges them by timestamp, and returns one list. Media never touches the post path — it uploads straight to the blob store and the post just carries media IDs.

Component deep-dives

Posting as a normal user — push fan-out

sequenceDiagram
    participant C as Client
    participant API as Post Service
    participant DB as Post Store
    participant K as Kafka fan-out topic
    participant W as Fan-out Worker
    participant G as Follow Graph
    participant R as Redis Timelines
    C->>API: POST /v1/posts {text}
    API->>DB: INSERT post (durable first!)
    API->>K: enqueue {post_id, author_id}
    API-->>C: 201 Created (fast — fan-out is async)
    W->>K: consume job
    W->>G: get follower IDs (paginated)
    loop each follower batch
        W->>R: ZADD timeline:{fid} ts post_id
        W->>R: ZREMRANGEBYRANK (trim to 800)
    end

The post is durable before the user gets a 201. Fan-out is async — the user sees their own post instantly via a read-your-own-writes path, followers catch up within seconds.

Reading a timeline — hybrid merge

sequenceDiagram
    participant C as Client
    participant T as Timeline Service
    participant R as Redis Timelines
    participant I as Celebrity Index
    participant D as Post Store
    C->>T: GET /v1/timeline?cursor=
    par fetch both paths
        T->>R: ZRANGE timeline:{me} (precomputed)
    and
        T->>I: recent posts from followed celebrities
    end
    T->>T: merge by timestamp, dedupe post IDs
    T->>D: hydrate post bodies for IDs (MGET cache first)
    T-->>C: 20 posts + next cursor

API + data model

POST   /v1/posts              { "text": "...", "media_ids": [] } → 201 { "post_id": "p_9f2..." }
GET    /v1/timeline?before_ts=&before_id=&limit=20
GET    /v1/users/{id}/posts   (profile timeline — reads post store directly)
POST   /v1/follow/{user_id}   → 204
DELETE /v1/follow/{user_id}   → 204

posts(post_id PK, author_id, text, media_ids[], created_at)
follows(follower_id, followee_id, created_at)   -- PK (follower_id, followee_id)

Redis:
  timeline:{user_id}  →  ZSET, score = created_at_ms, member = post_id   (trimmed to 800)
  celeb:{user_id}     →  ZSET of recent posts, only for top ~10K accounts
  post:{post_id}      →  HASH of hydrated post body (cache, short TTL)

Trade-offs

Failure modes

What I'd actually build

Opinionated. Steal this for the interview.

Stack: Go API services (fast, boring, great JSON throughput) behind an ALB. Kafka for the fan-out queue with idempotent consumers. Redis Cluster sorted sets for timelines, Postgres (partitioned by month) for posts + follows with read replicas, S3 + CloudFront for media. Celebrity detection: nightly Spark/batch job over the follow graph + manual override list. Deploy on Kubernetes with HPA on the fan-out workers keyed to Kafka consumer lag. Pagination cursors everywhere; feature-flag the celebrity threshold so you can tune it live.

Why not Cassandra for posts? At 73 TB/year, Postgres with monthly partitions and read replicas is simpler to operate and plenty fast for point lookups by post ID. Reach for Cassandra when a single region's Postgres can't keep up — that's a year-3 problem, not an interview problem.

🔬 Interactive: fan-out simulator

Post as a normal user or a celebrity, under push, pull, or hybrid — and watch the write amplification happen.

Analogy check: push = printing the article into every subscriber's paper overnight. Pull = inserting it only when someone opens that page. Hybrid = the newsroom picks per author.