Twitter/X Timeline: Interview Perspective

Don't guess at scope — this is a clarification moment, not a design moment. Confirm whether this is the Following feed, a For You feed, or both, per Opening Move.

• "Are we designing Following or For You?" — Tests whether the candidate treats these as genuinely different candidate-source problems rather than one interchangeable feed.
• "Does a new post need to appear immediately?" — Tests whether the candidate connects this answer to a specific consistency choice, not just a general preference.
• "How many accounts can a user follow?" — Tests awareness that an unbounded following count is exactly what makes naive read-time generation fail.
• "Do we need replies/reposts in the feed?" — Tests whether the candidate recognizes this expands candidate sources and dedup rules rather than being a free addition.

Walk through fanout-on-write, per Fanout-on-Write, then explain why it alone doesn't scale to every account.

• "Why not generate every timeline at read time?" — Tests whether the candidate can articulate the O(accounts followed) read cost, not just recite that it's slow.
• "What happens if the author has 50M followers?" — Tests whether the candidate identifies write amplification as the actual bottleneck, not just 'it would be a lot of writes.'
• "How do you decide push vs pull?" — Tests awareness of the Fixed vs Adaptive Fanout Policy decision.
• "What if the author crosses the threshold?" — Tests understanding of strategy transitions, not just the steady-state cases.

Explain the idempotency key concept from Fanout Queue & Worker Architecture — using the post ID as the inbox member makes a repeated write a no-op.

• "How do you make fanout idempotent?" — Tests whether the candidate names the specific (timeline_owner_id, post_id) uniqueness, not just the word 'idempotent.'
• "What if the worker crashes halfway through a follower batch?" — Tests understanding of chunked, checkpointed fanout rather than one giant atomic job.
• "How do you know which followers already received it?" — Tests whether the candidate connects this back to checkpointing progress per batch.
• "How do you recover from a six-hour backlog?" — Tests awareness of controlled drain rate and backlog-age SLOs, per Fanout Backlog / Partial Delivery.

Point to Social Graph Access Patterns — this is an adjacency-list style access pattern, paginated for high-degree nodes.

• "What if the author has 100M followers?" — Tests whether the candidate reaches for paginated traversal rather than assuming a single query returns everything.
• "How is this different from finding who a user follows?" — Tests whether the candidate distinguishes the two access directions rather than treating them as the same lookup.
• "Would you use a graph database?" — Tests whether the candidate over-commits to one storage technology rather than recognizing the access pattern is what matters.
• "What happens if the Social Graph service is down?" — Tests failure-mode reasoning, per Social Graph Service Unavailable.

Explain that ranking always operates on a bounded candidate pool, per Candidate Generation & Feed Composition, not every post in the system.

• "Do you send every post from every followed account into the ML model?" — Tests whether the candidate separates candidate generation from scoring, a common conflation.
• "How do you keep candidate count bounded?" — Tests understanding of merge/dedupe/discard steps before ranking ever runs.
• "Where do filtering and deduplication happen?" — Tests whether the candidate connects this to Post Lifecycle, Deletion & Visibility.
• "What if ranking takes 500ms?" — Tests timeout-budget reasoning, per Ranking Service Unavailable.

Explain why offset breaks down and present the cursor model, per Feed Pagination & Stable Scrolling.

• "Why not OFFSET/LIMIT?" — Tests whether the candidate can explain instability against a changing dataset, not just state that it's 'bad practice.'
• "What if new posts arrive between page 1 and page 2?" — Tests whether the candidate reasons about a stable snapshot or materialized result as the fix.
• "What if ranking scores change?" — Tests recognition that ranked-feed pagination is genuinely harder than chronological pagination, not the same problem.
• "How do you avoid duplicate posts?" — Tests whether the candidate connects this to client- or server-side deduplication as a practical mitigation.

Explain serving-time validation, per Post Lifecycle, Deletion & Visibility — correctness comes from read-time filtering, not synchronous cleanup everywhere.

• "Do you delete it synchronously from all 10 million inboxes?" — Tests whether the candidate recognizes this as unnecessary and expensive, and proposes async cleanup instead.
• "What if the author blocks the reader?" — Tests whether the candidate generalizes the same read-time filtering mechanism to a different visibility trigger.
• "What if the account becomes private?" — Tests the same generalization again — one mechanism, several triggers.
• "How quickly must deletion propagate?" — Tests the distinction between correctness now (read-time filtering) and cache-invalidation speed as a separate, secondary concern.

Walk through Timeline Cache Fails — fall-through to composition, degraded-mode options, and stampede prevention on recovery.

• "Can the database survive every request becoming a miss?" — Tests whether the candidate reasons about downstream capacity limits, not just 'it falls through.'
• "How do you prevent a thundering herd when Redis recovers?" — Tests knowledge of jitter, request coalescing, and gradual warming.
• "Would you serve stale data?" — Tests whether the candidate offers a concrete degraded-mode option rather than treating 'serve nothing or serve everything fresh' as the only choices.
• "What functionality would you degrade first?" — Tests prioritization: chronological fallback and reduced page size before an outright outage response.

Explain derived-state rebuild, per Timeline Inbox Lost / Redis Cluster Loss — posts are never at risk, only the precomputed candidate structure.

• "Is the inbox source of truth?" — Tests the source-of-truth-vs-derived-state distinction directly, per Data Ownership & Storage Model.
• "How would you rebuild it?" — Tests whether the candidate names a concrete rebuild source (recent posts from followed authors) rather than a vague 'recompute it.'
• "Would you rebuild all users immediately?" — Tests prioritization and rate-limiting reasoning, not an uncapped all-at-once rebuild.
• "What would the user see while rebuilding?" — Tests whether the candidate proposes a temporary read-time composition fallback rather than an outright error.

Tests whether the candidate recognizes this stresses the pull/read side (fanout-on-read cost scales with accounts followed), the opposite pressure point from the celebrity write-side problem.

• "Would this change your fanout classification?" — Tests whether the candidate recognizes follower count and following count are different axes of the same fanout-cost question.

Combine Celebrity Post Storm reasoning with general read-surge handling — write amplification is contained by hybrid fanout, but read-side and request-layer capacity still matter.

• "Which layer absorbs most of that surge?" — Tests whether the candidate names cache and read replicas specifically, not just 'the system handles it.'

Tests whether the candidate keeps Following and recommendation feeds as separate candidate sources rather than silently merging them into one undifferentiated feed.

• "Do they share any infrastructure?" — Tests whether the candidate identifies shared components (ranking service, object cache) versus genuinely separate candidate-source logic.

Tests whether the candidate reasons about a stale, likely-evicted or never-fully-populated inbox, and proposes read-time composition or a partial rebuild rather than assuming the precomputed inbox is simply ready to serve.

• "Would you keep pushing fanout to inactive users the whole time?" — Tests cost-awareness — pushing fanout to a user who never reads it is pure waste, worth reconsidering for very inactive accounts.

Tests recognition that this compounds several scenarios at once — hot partition pressure on the object cache, celebrity-storm-style read pressure, and elevated ranking load — not a single isolated failure mode.

• "Would your mitigations from the individual scenarios still work together?" — Tests whether the candidate can reason about compounding failure modes, not just recite each mitigation in isolation.

Tests prioritization under constraint — a strong answer identifies that hybrid fanout classification, a full ranking model, and multi-layer caching are all scale-justified investments that could be deferred, while basic fanout-on-write and a durable Posts DB cannot.

• "At what point would you introduce each deferred piece?" — Tests whether the candidate ties each simplification back to a specific scale threshold rather than treating the MVP as a permanent design.