For a social network's hybrid home timeline, how would you set the follower-count threshold that decides which accounts are pushed versus pulled?
answer
- two budgets, not one number
- throughput times lag target
- merge width per reader
- active followers times posting rate
- avoid flapping at the boundary
basics
~20 sDerive it from budgets rather than a fixed number: the largest fanout the pipeline can finish within its delivery-lag target, weighed against how many pulled accounts a reader can merge per read. Count active followers and posting rate, and add hysteresis.
solid answer
~50 sI would treat the threshold as a policy derived from two budgets. On the **write side**, a post must reach followers within a lag target: with 100,000 inbox writes per second and a 10-second target, one post can reach at most 1,000,000 followers even with nothing else queued, and reserving only 20% of capacity for any single account gives about 200,000. On the **read side**, every pulled account adds one outbox read and widens the merge for each of its followers, so a threshold set too low leaves some readers merging hundreds of lists. Between those bounds I would use **active** followers and **posting rate** rather than raw follower count, since cost is active followers times posts. I would add **hysteresis** so accounts near the line do not flap, define what happens to existing inbox entries when an account switches, and revisit the number from measured fanout lag and read latency rather than fixing it once.
go deeper
Recall that the threshold separates accounts whose posts are copied to followers from accounts whose posts are fetched at read time.
Explain the push cost formula, active followers times posts, and the extra read each pulled account adds per follower.
Derive a bound from fanout throughput and a lag target, and describe hysteresis and mode transitions.
Balance the write and read budgets explicitly, justify the signals you use, and describe how the boundary is measured and revisited.
## Framing the decision A **hybrid** home timeline pushes posts from ordinary accounts into followers' precomputed inboxes (**fanout-on-write**) and merges posts from very high-follower accounts at read time (**fanout-on-read**). The threshold that separates the two is not a universal constant. It is where the marginal cost of pushing an account's posts exceeds the marginal cost of pulling them, subject to latency targets on both paths. ## The write-side budget Pushing an account costs, per day: `push writes/day = active followers x posts per day` and, per post, a fanout job whose duration is `active followers / fanout throughput`. Illustrative numbers, assuming a fanout fleet sustaining 100,000 inbox writes per second and a delivery-lag target of 10 seconds: - Upper bound with an empty queue: 100,000 x 10 = **1,000,000** followers per post. - Realistic bound, reserving at most 20% of capacity for one account's post: 20,000 x 10 = **200,000** followers. - An account with 200,000 active followers posting 50 times a day generates 10,000,000 writes a day on its own. The realistic bound is the one that matters, because many posts fan out concurrently and bursts happen around live events. ## The read-side budget Pulling an account shifts cost to every reader who follows it: - each timeline read adds **one outbox read** per pulled followee; - the **merge width** grows by one for each such followee; - the pulled account's outbox becomes a heavily shared read target, which must be cached well. The binding constraint is usually merge width per reader, not total reads. If the threshold is set too low, many mid-sized accounts become pulled, and readers who follow many of them pay for large scatter-gather reads with poor tail latency. ## Inputs that beat raw follower count | Signal | Why it matters | |---|---| | Active followers | Dormant followers cost nothing if fanout already skips them | | Posting rate | A large but quiet account is cheap to push | | Burstiness | Accounts that post in bursts during events stress the queue | | Follower overlap | Readers who follow many pulled accounts widen merges | | Freshness needs | Pulled posts appear instantly; pushed posts wait for fanout | A practical rule is a score such as `active followers x posting rate`, compared against a write budget, with a floor on active followers so small accounts are never pulled. ## Operating the boundary 1. **Hysteresis.** Switch to pulled above one value and back to pushed only below a lower one, so an account hovering near the line does not flip on every recount. 2. **Transitions.** When an account becomes pulled, stop fanout; existing entries stay in inboxes and age out, and the read merge deduplicates by post ID. When it becomes pushed again, either backfill recent posts into inboxes or keep merging its outbox for a grace period. 3. **Per-reader escape hatch.** For a reader whose merge width exceeds a cap, push those accounts to that reader anyway, or maintain a precomputed merged list for them. 4. **Measurement.** Track fanout lag percentiles, queue depth, timeline read p99, and merge width distribution; move the threshold when one budget is consistently under-used while the other is strained. ## Trade-offs a lead should state - **Lower threshold:** fanout lag improves and write cost falls, but read cost and read latency rise, and more hot outboxes must be protected. - **Higher threshold:** reads stay simple, but a few huge fanout jobs can dominate the pipeline during bursts. - **Static versus dynamic:** a static number is easy to reason about; a dynamic score reacts to growth but needs guardrails and explainability. - **Organizational cost:** two delivery paths mean two sets of bugs, and every timeline feature must work on both. There is no single right number. A strong answer derives a range from explicit budgets, names the signals that refine it, and describes how the boundary is operated and revisited.
- Why is raw follower count a weaker signal than active followers times posting rate?Push cost is the number of writes actually performed. Dormant followers are often skipped already, and an account that posts once a month costs little regardless of audience. Multiplying active followers by posting rate estimates the real write load, so a large but quiet account can stay pushed while a mid-sized, very active one may need pulling.
- What happens to readers if the threshold is set too low?Many mid-sized accounts become pulled, so readers who follow lots of them must fetch and merge many outboxes on every refresh. Merge width and tail latency climb, and the timeline starts behaving like pure fanout-on-read for exactly the heaviest readers.
saying these in an interview costs you the question
- There is a standard threshold every social network uses.
- Lower thresholds are always better because they reduce writes.
- Raw follower count alone captures the real push cost.
- Switching modes needs no handling of existing inbox entries.
- Only the write side constrains where the threshold sits.