How to Architect Twitter’s Feed: Push vs Pull Strategies Explained

Today we discuss how to design Twitter.

Designing Twitter is a classic interview question; we first consider what Twitter fundamentally is—a feed stream. A feed consists of many lists, and the aggregation of these lists forms the final result, similar to how Kafka aggregates log streams by time. Besides Twitter, many popular applications such as Facebook, Weibo, WeChat Moments, Google Reader, and Toutiao also rely on feed streams.

To illustrate, consider a concrete example in Twitter. We have three feed lists. Note that terminology varies across companies; here a "feed" refers to a single list, while the collection of lists is called a "timeline". The timeline aggregates the feeds. In the diagram, the first column is Nelson’s list, the second is Tim’s list, and the third is QCon’s list. Each user’s personal feed can be combined.

When these lists are merged, we get a timeline. This concept is crucial: each individual list belongs to a user (e.g., your own posts, your mother’s posts, your father’s posts). The three lists together form the timeline you see in a social feed. Understanding this helps with later sections.

Besides each user’s own list, the second essential concept is the social graph: the follower/friend relationships. These relationships allow the system to gather all the information from the people you follow into a single result. For simplicity we treat the graph as directed, though it can represent undirected relationships as well.

According to our system design principle SNAKE (Scenario, Necessary, Application, Kilobit, Evolve), we first need to understand the scenario, which we have already introduced.

The next step is to consider constraints. What are Twitter’s limits? The read QPS for a user’s timeline is about 300 k requests per second, while the write QPS is only about 5 k. This reflects the typical pattern where reads far outnumber writes.

Twitter also needs a notification system. When a celebrity like Lady Gaga, who has tens of millions of followers, posts a tweet, the system must deliver that notification to all followers within seconds, aiming for up to one million notifications per second.

To achieve this, two modes are possible:

Push mode – the system actively pushes the update to all followers.

Pull mode – followers request (pull) the update when they need it.

Push mode details.

In any mode we care about reads and writes. In push mode, when a user writes a tweet (e.g., “Hello, I’m Fannec”), the write API not only stores the tweet but also broadcasts it to all followers. The system reads the follower graph and fan‑out the message with O(n) complexity, where n is the number of followers. For a user with 10 k followers, 10 k messages are generated, making the write O(n). Reading a timeline is then O(1) because the timeline is pre‑assembled.

The main drawback is the “Lady Gaga problem”: a user with millions of followers would require broadcasting millions of messages at once, causing a write bottleneck.

Pull mode details.

In pull mode, the write is cheap: the tweet is stored only in the author’s own list (O(1)). However, when a user wants to read their timeline, the system must gather posts from all the lists they follow, which incurs O(n) read cost. This flips the trade‑off: writes are cheap, reads become expensive.

Both push and pull have limitations. The push mode suffers when a user has many followers; the pull mode suffers when a user follows many others. A hybrid approach—using push for users with few followers and pull for high‑follower users—can mitigate these issues.

The hybrid approach raises the question of where to set the follower‑count threshold. A hard threshold can cause “flapping” when a user’s follower count hovers around the limit (e.g., due to removal of fake accounts). To avoid this, a range threshold is recommended: push when followers < 90 k, pull when followers > 100 k, with a buffer zone in between to prevent rapid switching.

When interviewing, you can decide between push and pull by considering three criteria:

Understand the scenario (e.g., group chat in WeChat is better suited for push because the group size is limited).

Balance latency, computation, and storage requirements based on your infrastructure and expected growth.

Assess whether O(n) operations are feasible in a distributed environment; even O(n) can be too costly if the constant factor is large.

In practice, many large systems pick a single strategy and optimize it heavily. Facebook uses pull for all users, while Instagram uses push for all users. The key is to choose one method and fine‑tune it rather than trying to implement both.

That concludes the first part of the series. Next time we will dive deeper into how to improve Twitter’s architecture in a distributed environment.

Source: Top Programmer