Design a microblogging service

01Define publication and the home feed

Design a service where users publish short posts, follow authors, like posts and browse a chronological home feed. Replies reference a parent post; reshares reference an existing post while recording who shared it. Maya publishes “The bridge is open” as post p701. Leo follows Maya and should see p701 when he refreshes his feed.

For this exercise, limit text to 500 characters with an explicit Unicode counting rule. A successful publish means the post is durably stored and can be read from Maya’s profile. Leo’s feed may take a few seconds to include it. These are different completion conditions: storing a post does not mean every follower’s page has been updated.

Include deletion, private accounts and a bounded history of recent feed entries. Media uploads finish before a post references them. Begin with chronological ordering, not recommendations. Search, trends and notifications are separate consumers of published events; explain their boundaries if asked, but do not build them into the critical publication path. Global real-time ordering across all authors is also outside this interview’s contract.

Ask whether the home feed must be chronological or ranked, whether a post must appear to every follower before publish succeeds, and how private accounts behave. These choices determine the consistency and fanout work we actually need.

02Functional requirements

Agree on these supported actions before selecting components.

1. Publish and manage posts. Authenticated authors create and delete short posts, with verified media references and a 500-character limit under a declared Unicode counting rule.

2. Follow and browse. Users follow/unfollow authors, view author profiles and page through a chronological home feed of eligible followed posts.

3. React, reply and reshare. Support likes, replies linked to a parent and reshares linked to the original post. Deletion or privacy changes of the source still govern disclosure.

4. Recover repeated actions. Retries of one creation return its existing post; repeated like/unlike operations preserve the intended user/post relationship.

03Non-functional requirements

Use these as illustrative interview assumptions to agree with the interviewer. Numerical targets require measurement; they are not claims about an existing product or a proven implementation. p95 (the 95th percentile) means 95% of measured operations finish within the stated time.

1. Workload. Use 100 million posts/day and approximately 81,019 page requests/s at the fivefold peak. Include the fifty-million-follower celebrity case and media bytes rather than sizing from the average post rate alone.

2. Response time. Target regional p95 post-acceptance and feed-page latency of 300 ms under the admitted peak workload in normal operation. Media downloads are measured separately from the metadata page.

3. Feed freshness. Target p95 propagation from source commit to the prepared candidate list or author history used by an eligible active follower’s refresh within five seconds during normal processing. Publication does not wait for every follower; bounded retrieval may omit a post, and older pages may require refresh to consider late candidates.

4. Source durability. Accepted posts, retry results, relationships and publication work must survive a process restart or one database-node failure within the region. Prepared inboxes are rebuildable views, not the only source of a post.

5. Current access. Check current post visibility and relevant private-account relationships before returning content. Cached candidates and a ranking fallback cannot authorize a now-private or deleted post.

6. Bounded serving work. Cap candidates, follower batches and retained inbox windows. Choose incomplete but authorized pages or explicit overload responses over unbounded work; exact global ordering and exact engagement totals are outside the contract.

04Follow one post from creation to a reader

Start with one application and a replicated SQL database. Maya sends a create request with request key post-71. In one transaction the application inserts p701 and saves the request key’s result. It replies after commit. If the reply is lost, retrying post-71 returns p701 instead of creating a second post.

A profile request uses an index ordered by author and creation time. Leo’s home-feed request first reads the authors he follows, retrieves their recent posts and merges those ordered results. It returns the newest twenty eligible posts. This is fanout on read: one viewer request gathers candidates from several authors. Nothing needs to be copied into Leo’s account when Maya publishes.

Like actions use a unique pair of user ID and post ID. Repeating “like p701” leaves one relationship rather than incrementing an unprotected counter twice. A reshare stores p701’s identity instead of copying its body, so deleting the original can hide it everywhere that checks that reference.

This baseline is complete for modest traffic. Its weakness appears when many readers repeatedly merge the same author histories. We can measure that work before introducing background workers or precomputed feeds.

05Estimate pages, candidates and media separately

Assume one billion registered users, 200 million daily users and 100 million posts per day. Each daily user opens two home-feed pages and five profile pages, with twenty posts per page. Use decimal bytes and a fivefold peak multiplier.

If Leo follows 200 authors and we fetch twenty candidates from each, one home page examines up to 4,000 candidates to return twenty. Across approximately 4,630 home-feed requests/s, that is roughly 18.5 million candidates/s. Profile reads have different costs and should not be included in that multiplication.

The opposite extreme is also expensive: copying a celebrity’s post to fifty million followers takes 1,000 seconds at 50,000 inserts/s. Average follower count hides this problem. Measure audience activity and the distribution of follower counts before choosing a fanout policy.

06Make retries and pagination explicit

The API exposes user intent while deriving the acting user from authentication. The request key belongs to one author and one payload; reusing it with changed text is an error.

Create-post request

POST /v1/posts

After commit, the running example returns post ID p701.

Use a cursor containing the last returned creation-time/post-ID pair and an initial upper cutoff. Numeric offsets shift when newer posts arrive. Keyset pagination avoids that shift, but it is not a frozen snapshot: a late fanout entry can still be missed until refresh. State that limitation. Current visibility checks run on every page even when its candidate list was prepared earlier.

07Keep source records separate from prepared feeds

A post is the source of its text, visibility and media references. An inbox entry is only a possible item for a viewer’s feed. Keeping that distinction allows the system to rebuild feeds without recovering post bodies from many inconsistent copies.

An outbox is a database table of work that remains to be sent to other services. Saving its event in the post transaction closes the gap where p701 commits but the application crashes before notifying feed workers. A relay can send that event later and may send it more than once.

Choose author-owned database partitions for the scaled design. Post, request result, outbox and author/time index commit together within the owning partition. A post ID carries routing information or is resolved through a routing directory. Globally unique identifiers alone do not provide an efficient query for all posts by one author.

08Precompute the feeds that readers actually reuse

Add fanout on write for ordinary authors with active followers. A worker reads Maya’s followers in bounded pages and inserts p701’s ID into their inboxes. Leo’s next feed request becomes a short inbox range query followed by loading the matching posts. This exchanges background writes and storage for less repeated work during reads.

Do not apply that policy to every author. Very popular authors remain on the pull path: save their recent posts once and merge them into followers’ feeds at read time. The worked design is therefore hybrid. An ordinary post generates inbox references; a celebrity post does not initiate a massive follower scan. Determine the threshold from measured recipient-write costs and useful reader requests, not a famous fixed number.

The read service merges Leo’s inbox with recent lists of the popular authors he follows, removes duplicate IDs, loads post records in batches and checks current visibility. Bound candidates and source lists so an unusual follow graph cannot consume unbounded work. An incomplete but authorized page is preferable to a timeout caused by searching forever for twenty items.

Keep only a useful recent window in inboxes and rebuild a bounded window for returning inactive users. Store media in object storage and deliver it through an authenticated media edge backed by a content delivery network. The edge checks current access before serving cached private bytes. Already downloaded content cannot be recalled, and an in-flight transfer is not an instantaneous revocation guarantee.

Choose durable majority commits across three replicas in independent regional failure domains for each authoritative database group. This implements the one-node-loss target for source posts, relationships and saved publication work; candidate caches remain rebuildable. Benchmark both page latency and active-follower freshness before increasing admitted load.

09Recover partial fanout without skipping followers

Suppose the worker inserts p701 for viewer A, then crashes before viewer B. Retrying the entire page is safe because the inbox key is unique per viewer/post. A’s duplicate insertion changes nothing; B receives the missing entry. The worker records the next page checkpoint only after every insertion in the current page succeeds.

The checkpoint is durable progress, not a note that a worker fetched a job into memory. A repeated queue event resumes or repeats work using the same post identity. Use a conditional checkpoint update so two workers cannot overwrite newer progress with an older position. Workers may repeat the operation, but those repeats leave the same inbox entries. The queue need not deliver exactly once.

Follower relationships can change during the scan. Handle new follows with bounded backfill and check current follow/private-account rules while serving. The scan does not pretend to capture a globally frozen social graph. Likewise, changing an author between push and pull policies may temporarily produce the same candidate through both paths; ID deduplication makes that transition harmless.

If the fanout queue is behind, p701 remains visible on Maya’s profile while follower feeds lag. Add workers only while inbox storage has spare capacity. Unlimited consumers can turn a freshness problem into a database outage.

10Deletion changes eligibility, not just storage

Deleting p701 marks its source record deleted and records a cleanup event. Inbox, search and cache references may remain temporarily. They cannot be treated as permission to reveal the body. Before returning a candidate, load its current visibility and the membership needed for private access; if that check cannot be completed, omit or fail that item rather than guessing.

The same rule applies to reshares. A reshare can retain an actor and timestamp for internal history, but it cannot resurrect text from an inaccessible original. Removing stale references later reduces wasted work; it is not the mechanism that protects private content.

Like counts may briefly lag because they are computed from relationship changes. That is acceptable for a display count, while the unique user/post relationship answers whether Leo has liked p701. Do not reuse this approximate-count reasoning for authorization. Freshness, popularity and permission have different consequences when stale.

11Measure freshness and protect the source of truth

Track post acceptance latency, home-feed latency, candidates examined per page and oldest unprocessed fanout event. Measure the delay until an active follower can see a newly eligible post. A fast page showing yesterday’s content passes a latency check but fails a freshness goal.

Rate-limit publication, follows, likes and media upload separately. One small post can trigger millions of follower writes, so abuse limits must account for that work as well as request count. Validate media ownership and readiness before referencing it. Protect hot post records with batched reads and caches, but preserve the current-access check for disclosure.

During ranking or optional analytics outages, serve a chronological eligible feed. During permission-store failure, do not use that fallback to expose uncertain private posts. Database replicas, backups and restore exercises protect source posts and relationships; inboxes can be reconstructed from those sources.

Cost comes from media storage and delivery, fanout writes, repeated candidate merges and retained indexes. Compare those quantities for active audiences. A lower database query count is not automatically a cheaper system if it requires millions of never-read inbox entries.

12Check the design against the requirements

Use the agreed lists to check the finished design. The tests below still need to establish the targets; a proposed mechanism is not a measured result. FR refers to the numbered functional requirements above; NFR refers to the numbered non-functional requirements.

13Rapid revision

Remember: A post commits once; follower copies can arrive later. Save fanout progress only after the inbox writes finish.

For a final explanation, walk p701 through commit, recoverable fanout, candidate merge and current visibility checking. Then name the tradeoff: the service accepts a few seconds of feed propagation delay to avoid a transaction across every follower. A stricter repeatable feed session or global publication order requires an additional contract and mechanism; neither is supplied merely by choosing a distributed database.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.