Design Twitter

Clarify the ask

The interview prompt is short. Design Twitter.

A short prompt hides many choices. Each choice is settled out loud before it shapes the design.

The design must name its users, its main write and its main read. It must also name what stays out of scope.

Posting is the main write. The home timeline is the main read. Search is the second read.

Direct messages stay out of scope. A new post may reach followers a moment late.

Functional requirements

Posting is the main write. A user writes a short post and publishes it for followers to see.

Following is the link that shapes reading. A user follows an account to see that account's posts.

The home timeline is the main read. It shows recent posts from followed accounts, newest first.

Search is the second read. A user searches posts by the words they contain.

Likes and replies support the main flows. They add engagement counts and threaded replies to a post.

Direct messages stay out of scope. Video posting stays out of scope. The design covers short text posts.

Non-functional requirements

The timeline must open fast. Reading is the hot path, so a slow timeline fails the design.

Posting must stay available. A user can post even when parts of the service are under strain.

A post must not be lost after posting reports success. Durability matters more than speed on the write path.

Freshness can lag a little. A follower may see a new post a moment late, and that is acceptable.

Scale in one view

The design assumes 500,000,000 posts a day. That figure is the stated scale for this problem.

Reads run at 100 reads per write. The service is read-heavy by a wide margin.

These counts turn into rates and storage below. Those rates decide where the design spends its effort.

Where the depth sits

The news feed problem in the earlier course taught fan-out and the celebrity problem. This problem reuses both at a larger scale.

One account can have tens of millions of followers. Copying one post to every follower breaks the simple design.

Search and trends form a second system beside the timeline. Both systems must keep up with the same post stream.

Estimate the scale

The scale comes first. The counts come from the stated assumptions of this problem, starting with 500,000,000 posts a day.

500,000,000 posts ÷ 86,400 seconds = 5,787 posts per second.

Reads run at 100 reads per write.

500,000,000 posts × 100 reads = 50,000,000,000 timeline reads a day.

50,000,000,000 reads ÷ 86,400 seconds = 578,704 timeline reads per second.

That read rate is about 579,000 per second in round terms.

Estimate the storage

One post stored with its metadata takes 300 bytes.

500,000,000 posts × 300 bytes = 150 GB of new posts a day.

150 GB a day × 365 days = 54,750 GB of new posts a year.

Keeping three copies of every post turns 150 GB of new posts into 450 GB of new stored data a day.

Storage grows steadily and predictably. It needs sharding, but it never surprises the design.

What the numbers decide

The read rate dwarfs the post rate. The design spends most of its effort on reading timelines.

The post rate is modest. A single well-built write path can absorb the average post flow.

Reads and writes need different treatment. One design for both would serve neither well.

The data model

Three records carry the whole design.

A user record holds the user id, the display name and the account details.

A post record holds the post id, the author id, the text and the time it was posted.

A post id carries its creation time in its leading part. Sorting by post id then sorts by time.

A follow record holds the follower id and the followed account id. One record means one follow link.

Post records are sharded by author id. Follow records are sharded by follower id.

The API in plain text

Each operation is named with its fields in plain text.

Post a post takes the author id and the text. It returns the new post id.

Follow takes the follower id and the account id. It stores one follow record.

Read timeline takes the user id, a page size and a cursor. It returns a page of posts, newest first.

Search takes the query text and a cursor. It returns a page of matching posts.

The cursor marks where the last page ended. The next page starts after that mark.

Sharding and hot spots

Sharding by author id spreads posts evenly while authors post at similar rates.

A very active author can overload one shard. That overload is a hot spot.

Celebrity accounts are the sharpest hot spot in this design. The timeline gives them their own path.

Deep dive the timeline

The timeline is where fan-out meets the celebrity problem at full scale.

The earlier course taught two fan-out shapes. Fan-out on write copies a post into follower timelines at post time.

Fan-out on read stores a post once. The reader gathers posts from followed accounts at read time.

This design mixes both shapes. Normal accounts push. Celebrity accounts pull. The mix is called the hybrid design.

Fan-out on write costs one copy per follower. Its read cost is one lookup.

Fan-out on read stores a post once. Its read cost is gathering and merging.

The hybrid copies for normal accounts. Its read cost is merging celebrity posts.

Fan-out on write for normal accounts

A normal post is copied into each follower's timeline at post time. A queue carries the copies as background jobs.

A cached timeline holds post ids only. The post text stays in the post store and is fetched when a page is read.

Each cached timeline holds a capped number of recent post ids. Older ids fall off the end of the list.

Reading then costs one lookup. The reader fetches the ready list and then the posts on the page.

A repeated copy carries the same post id. The timeline stores that id once, so retries never duplicate a post.

The celebrity case in numbers

A celebrity account in this design has 50,000,000 followers. That is the taught figure for a very large account.

50,000,000 followers × 1 post = 50,000,000 timeline writes for one post.

At 100,000 writes per second, those writes take 500 seconds, about 8 minutes.

One post would keep the write path busy for minutes. Normal posts would queue behind it and land late.

The write storm is the celebrity problem. Scale turns a working design into a failing one here.

Fan-out on read for celebrity posts

A celebrity post is stored once, with no copies. Followers pull it when they read.

At read time, the service fetches the latest posts from the celebrity accounts the reader follows. It merges them into the cached timeline list by post id.

The merge list is short. Only the celebrity accounts a reader follows add work to that reader's read.

Pure fan-out on read would cost far more. A reader who follows 200 accounts and checks the latest 20 posts from each sorts 4,000 candidate posts on every read.

200 accounts × 20 posts = 4,000 candidate posts per read under pure fan-out on read.

At the full read rate, that gathering work is unaffordable. The hybrid keeps gathering only for celebrity posts.

Ordering and ranking

The merged timeline is ordered by post id. Post ids carry their time, so the order is newest first.

Feed ranking can then reorder the page. Ranking scores the short merged list, never the whole post store.

Ranking favours recent posts and posts with strong engagement. The exact scoring stays a replaceable part behind the timeline.

A pushed post can land a moment after a pull merge ran. The next read shows it, and that small lag is the accepted freshness cost.

Where the design breaks

A lost cache server takes its cached timelines with it. Reads fall back to gathering from followed accounts until the cache rebuilds.

The rebuild copies recent posts for each affected user. It runs as background jobs and favours active users first.

A celebrity post can also draw a read storm. The celebrity's recent posts are cached once and shared by all readers.

Each failure has a plainer fallback. The design bends toward slower reads, never toward lost posts.

Deep dive search and trends

Search and trends both feed on the same stream of new posts.

Search must answer from words, not from authors. A separate index exists for that shape of question.

Trends must react within minutes. A slow batch count would report yesterday's news.

Indexing posts as they arrive

An inverted index is a lookup from a word to the posts that contain the word.

Each new post is split into its words. Every word gains the post id in its list.

Indexing runs as background jobs fed by a queue. Posting never waits for indexing to finish.

The index is sharded. Each shard holds the word lists for a set of words.

A search asks the shards for its words and merges the answers. No single shard holds the whole index.

The indexing load in numbers

New posts arrive at 5,787 posts per second on average.

5,787 posts per second × 600 seconds = 3,472,200 posts in a 10-minute window.

The index must absorb that flow without falling behind. A growing lag means newer posts stay invisible to search.

Index workers scale with the post flow. Adding workers adds indexing capacity without touching the post path.

Answering a search

A search looks up each query word in the index. The matching post id lists are combined.

A post must contain the query words to match. Combining the lists keeps only posts on the shared part.

Results return newest first. A cursor carries the reader through further pages.

Popular searches are cached for a short time. A cached answer can lag the newest posts by a short while.

That lag is acceptable for search. The newest post matters most in the timeline, not in results.

Counting trends from the stream

A trend is a word or hashtag rising fast. A hashtag is a label a writer adds to a post.

Counters track each word over short time windows. Counting happens in memory as posts flow past.

The current window is compared with earlier windows. A word rising sharply stands out from steady words.

Counting every post exactly is heavy. Counters give a close count fast, and a close count ranks trends well.

Trends are counted per place as well as globally. A local event can trend in one place and nowhere else.

Where search breaks

A major event floods one word. That word's list grows fast, and its shard takes heavy read load.

Hot results are cached hard during the event. Splitting the hot word across shards spreads the remaining load.

Index lag can grow under a posting burst. Search then serves a slightly older index and says results may lag.

The timeline never depends on the index. Search can degrade while posting and timelines stay healthy.

Evaluate the design

Evaluation is the last step of the interview method.

Each choice bought something and cost something. Naming both sides is the point of this step.

Hybrid fan-out gains fast reads. It costs two paths to maintain.

Cached timelines gain low read latency. A post can land late.

A sharded word index gains search at scale. Hot words can overload a shard.

Consistency against latency

A timeline is not strongly consistent in this design. Two followers can see the same post at slightly different moments.

PACELC extends the CAP choice. It says a system also trades consistency against latency in normal running, when nothing has failed.

This design picks latency in normal running. A cached timeline can miss the newest post for a short while.

The author always sees their own post at once. That one read goes to the post store, not the cache.

Cost against freshness

The hybrid design runs two paths. Push serves normal accounts, and pull serves celebrity accounts.

Two paths cost more to build and to run. One path alone either storms on celebrity posts or gathers on every read.

A follower-count threshold draws the line between the paths. Lowering it moves write cost into read cost.

Raising the threshold does the reverse. The threshold is a tuning choice, not a fixed law.

Availability and failure

Post and timeline data live in more than one data center. Losing one data center leaves the others serving.

Reads then serve slightly older timelines. Posting queues work and retries it when the lost capacity returns.

Graceful degradation is the pattern throughout. The service gets slower or staler before it stops.

No single failure loses a post that reported success. Replication carries that promise.

What the design leaves open

Ranking quality stays a seam. Better scoring can replace the simple ranking without touching fan-out or storage.

Abuse and spam filtering sit beside the post path. They are named here and designed elsewhere.

Search relevance can grow past newest first. The index shape already allows a scored order later.

The wrap-up

The hybrid fan-out carries the timeline at this scale. Push keeps normal reads cheap, and pull keeps celebrity posts affordable.

A word index carries search, and window counters carry trends. Both feed on the same post stream without slowing it.

The design trades a little freshness for fast reads throughout. That trade is the heart of this problem.

The estimate at a glance