Design Post Search

Keyword search over a billion users’ posts, searchable seconds after posting, sorted by recency or likes, hiding every post the searcher may not see.

Last updated 2026-10-26. Difficulty: hard. Patterns: search, real-time, privacy, counting, time-partitioning. Reported at Meta, X, LinkedIn, Reddit, Pinterest, TikTok.

Functional requirements

• Search posts by keywords. Words, hashtags and quoted phrases, all terms required. The same analyzer runs on posts and on queries, so "Earthquakes" finds "earthquake" and a hashtag stays one term.
• Sort by Recent or by Top. Recent is newest first; Top weighs likes, comments, recency and closeness to the searcher. Two orderings with different access patterns, and one index has to serve both.
• New posts are searchable within seconds. People search what is happening right now: a goal, an outage, an earthquake. An index that is minutes behind misses the reason the search was typed.
• Likes and comments move posts in Top. A post that takes off rises within about a minute, and results show current counts. Likes arrive at a million a second, which is the constraint.
• Results only include posts the searcher may see. Public posts, friends-only posts by the searcher’s friends, custom audiences that include them, and their own posts. Nothing by anyone they blocked or who blocked them.
• Deletes, edits and audience changes apply quickly. A deleted post stops appearing at once. An edit must stop matching the words it removed, or search reveals what was taken out.
• Page through results. Infinite scroll with a cursor. Posts arriving in the meantime must not duplicate or skip results on the next page.
• Out of scope. People, page and group search; typeahead (its own question); spelling correction and semantic retrieval; ads in results; how posts are stored beyond what search needs.

Non-functional requirements

• Never show a post the viewer cannot see (0 leaks). The requirement behind the hardest tradeoff. A post missing for a few seconds is a shrug; a friends-only post shown to a stranger is a privacy incident. So results are personal, every one is re-checked against the source of truth, and caching is limited to what is the same for everyone.
• Freshness (searchable p99 < 10 s). Typically 1–2 s from commit. Rules out batch builds and periodic bulk refreshes: a post has to flow from the write path into an in-memory segment.
• Query latency (p99 < 500 ms). About 150 ms for the index fan-out, the rest for viewer context, counts and hydration. Latency follows the slowest partition, so partitions are replicated and requests hedged.
• Scale (50 k searches/s · 1 M likes/s). Peak rates, against 15 k posts/s. Likes outnumber post writes by about 65 to 1, so the engagement path, not the post path, is the write-heavy one.
• Corpus (~180 B posts/yr, kept for life). Tens of billions in any recent quarter, hundreds of billions overall. Most queries only need the last week, which is what makes tiering by time pay.
• Engagement in ranking (within ~1 min). Top reflects a surge in likes within a minute. Counts shown on results are read live at query time, so they are seconds fresh even where the index is not.
• Deletion (hidden at once · purged in days). Hidden from the moment the delete commits, out of the index within seconds, physically gone from every segment and snapshot within the purge deadline.
• Availability over completeness (99.95 %). Partial results beat an error: if a partition is slow, return what the others found and say so. This never extends to visibility, which is not negotiable.

Back-of-envelope estimates

• Post writes: ~6 k/s avg · ~15 k/s peak. 500 M posts/day ÷ 86 400 ≈ 5.8 k/s; evening peaks run ~2.5× that, ~15 k/s. Spread over 12 hot partitions that is ~1.25 k appends a second each. Writing new posts into the index is not the hard part.
• Like events: ~290 k/s avg · ~1 M/s peak. 1 B daily users × ~25 likes each = 25 B/day ÷ 86 400 ≈ 290 k/s, peaking near 1 M/s during live events. That is ~65× the peak post rate. This is the stream that must never rewrite an index document.
• Like-bucket changes: ~15 k/s avg · ~50 k/s peak. With power-of-two buckets, a post with n likes changes bucket only ~log2(n) times: 20 times on the way to a million. Most posts get a handful of likes and most likes land on a few popular posts, so assume ~2.5 changes per post over its life: 500 M × 2.5 ÷ 86 400 ≈ 15 k/s, about 20× fewer writes than likes.
• Index growth: ~100 GB/day · ~36 TB/yr. ~25 distinct terms per post with positions, compressed, ≈ 150 B, plus ~50 B of per-post fields (post id, author, time, audience, buckets) ≈ 200 B/post. 500 M × 200 B = 100 GB/day, ~36 TB/yr per copy before replicas.
• Hot tier size: ~700 GB · 12 partitions. Last 7 days = 3.5 B posts × 200 B ≈ 700 GB per copy. At ~60 GB of index per server that is 12 partitions. Small enough to hold entirely in RAM, which is what makes seconds-fresh appends and fast posting walks possible.
• Hot tier servers: ~240. Every query touches every hot partition. At ~2.5 k queries/s per replica (32 cores, ~10 ms of CPU per query), 50 k/s needs 20 replicas × 12 partitions = ~240 servers. Data size decides the partition count; query rate decides the replica count, separately for each tier.
• Viewer context per query: ~2.4 KB typical · 40 KB max. ~300 friends × 8 B ids = 2.4 KB; at the 5 000-friend cap, 40 KB, sent to each of 12 or more partitions. A Bloom filter at 1 % false positives needs ~10 bits per id, ~6 KB for 5 000 friends, and is safe only because the final check is exact.
• Exact-count reads: ~5 M keys/s peak. 50 k searches/s × ~100 finalists each = 5 M counter reads/s, batched into one multi-get per counter shard. Fetching counts for every match instead (a common term matches millions of posts) is what makes ranking on exact likes impossible at query time.

Components

• App / web: The search box and result list. Sends the query with a sort (Recent or Top) and an opaque cursor for the next page. The counts it shows come from hydration at query time, never from the index.
• API gateway: Authenticates the viewer and takes the viewer id from the session, never from the request, because every visibility decision downstream trusts it. Rate-limits searches per user and routes posts, likes and searches to their services.
• Post service: Creates, edits and deletes posts. Assigns a time-ordered post id (Snowflake-style, so the id carries the creation time), validates the audience, and commits the row. Search is not on this path, so a search outage cannot stop anyone posting.
• Post store (sharded by post_id): Source of truth for posts: text, author, audience, created_at, version, deleted flag, and a coarse like bucket. The index is derived from it and can always be rebuilt from it. The privacy check reads it for every result, so the index’s copy of visibility never has the final word.
• Change stream (Kafka · CDC, key = post_id): Committed post changes from CDC on the post store, keyed by post id so a post’s create, edits, bucket changes and delete stay in order. Indexers write analysed documents to one log per index partition, and every replica of that partition tails it: the log is the replication mechanism and the recovery path.
• Indexer (stateless consumers): Analyses text (tokenise, lowercase, hashtags and mentions as whole terms, positions for phrases) and builds the index document. Routes every event by the creation time in the post id and hash(post_id): a new post to the hot tier, an edit or delete to whichever tier owns the original. Idempotent on (post_id, version).
• Hot index tier (7 days in RAM · 12 × 20): The last 7 days, 12 partitions by hash(post_id), 20 replicas each. A single writer appends to a live in-memory segment while readers walk it lock-free up to a published watermark, so a post is searchable the moment it is appended, and postings are walked newest first. Like buckets, audience and deleted bits sit in per-document arrays that change in place.
• Archive tiers (weekly / monthly slices, SSD): Everything older than a week, in time slices (weekly for the last quarter, monthly before), each partitioned by hash(post_id). Posting lists on SSD, per-document arrays in RAM. Recent slices get more replicas because they are queried more, and each slice records its time range and per-term maximum engagement so queries can skip it.
• Segment builder (batch merges): Merges hot segments into the weekly slice once they age out of the hot window, and compacts weekly slices into monthly ones. Every merge writes only live documents and folds in edits, which is where deletion becomes physical. Writes slices to object storage for archive servers to load, and can rebuild any slice from a post store snapshot when the analyzer changes.
• Search service (plan · fan out · merge): Analyses the query with the indexer’s analyzer, loads the viewer context, and plans by sort: Recent walks tiers newest first and stops when the page is full; Top prunes slices by their engagement upper bounds. Merges partition results, fetches exact counts for finalists, re-ranks, and sends the page to the privacy check. Returns partial results with a flag rather than an error.
• Result cache (public slice · ~10 s): For hot queries only: (normalised query, sort, language) to the top ~500 public candidates with scores, kept about 10 s. It never holds friends-only posts or anything per viewer, so sharing it cannot leak; blocks and the friends branch are applied per request after the read.
• Social graph (friends · blocks, cached): Friend lists, blocks in both directions (who I blocked, who blocked me) and custom audience lists, in a cached graph store. Search reads the viewer’s context once per query, so an unfriend or a block applies to the very next search with nothing reindexed.
• Engagement counters (by post_id · in memory + log): Like and comment edges plus an exact counter per post, sharded by post id and held in memory with a durable log. The counter moves only when an edge is new, so a retried like counts once. A viral post’s counter is split into sub-counters summed on read; search reads ~5 M counts a second at peak for finalists.
• Like service (likes · comments): Takes likes and comments, writes the edge and increments the counter in the engagement store. Only when the new count crosses a power of two does it write the post’s like bucket to the post store, which turns ~1 M likes a second into ~50 k small row updates.
• Privacy check (canonical can-see rules): The one implementation of "can this viewer see this post", shared with feed and profile. Reads each result’s current row (deleted, audience, version, text) and checks it against the viewer context, blocks in both directions, and whether the current text still matches the query. The index may be stale in either direction; this check makes the dangerous direction harmless.

User flows

1. A post becomes searchable in seconds. The core write. The post commits to its own store first; search hears about it from the change stream and makes it visible in an in-memory segment without ever blocking the writer.
   1. The client publishes a post; the post service assigns a time-ordered id and commits the row. The id is Snowflake-style, so its high bits are the creation time and anything downstream can route by time without a lookup. Search is not on this path: with every index server down, posting still works and search catches up from the stream.
   2. Change data capture publishes the committed row to the change stream, keyed by post id. Reading the post store’s commit log means an event exists if and only if the row committed, with no dual write in the post service. Keying by post id keeps one post’s create, edits, bucket changes and delete in order. Typical lag is a few hundred milliseconds.
   3. An indexer analyses the text and builds the index document. Tokenise, lowercase, keep hashtags and mentions as whole terms, detect the language, and record positions for phrase queries. The analyzer is versioned because the query side must run the same one; changing it means rebuilding slices. The document carries only the fields queries filter and rank on.
   4. The indexer writes the document to the log of the hot partition that owns it. One log per index partition, and all 20 replicas of the partition tail the same log, so they converge without talking to each other. The log is also how a new replica catches up: it copies sealed segments from a peer and replays from their offset.
   5. Each replica appends it to the live in-memory segment and advances the searchable watermark. One writer thread appends to the posting lists; query threads read lock-free up to the last published document count, so there is no refresh step and no reader ever sees half a post. Twitter’s Earlybird paper describes this single-writer, many-reader design. Commit to searchable is typically 1–2 s.
   6. A Recent search a moment later meets it first, because postings are walked newest first. Documents get increasing ids in arrival order, so walking a posting list backwards is walking back in time. The newest post is the first thing a query sees, which is why being seconds fresh costs nothing on the read side.
   7. When the live segment fills, it is sealed into a compact read-only segment. Roughly an hour or two of posts per partition at peak. Sealing rewrites the postings into a compressed, read-optimised layout and opens a fresh live segment; queries read both. After 7 days, sealed segments leave the hot tier and are merged into an archive slice.
2. Search "earthquake", sorted by Recent. The core read. Visibility is applied inside the index walk using the viewer’s friend set, the walk stops as soon as a page is full, and every result is re-checked against the source of truth before it is shown.
   1. The client sends the query; the search service analyses it with the indexer’s analyzer. The same analyzer version as the index, or "Earthquakes" and "earthquake" stop meeting. The viewer id comes from the session at the gateway; a viewer id in the request would let anyone search as anyone.
   2. It loads the viewer context: friend ids, whom the viewer blocked, and who blocked the viewer. Read on every query from the graph cache, so an unfriend or a block applies to the next search with nothing reindexed. Both block directions matter: the viewer must not see posts by someone who blocked them. Typical size is ~300 friends, 2.4 KB; the cap is 5 000.
   3. The search service fans the query out to all 12 hot partitions with the visibility filter. Each partition walks postings newest first and admits a candidate only if its author is in neither block list and it is the viewer’s own, public, friends-only by a friend, or custom by a friend (flagged for the exact check). It stops after k admitted hits; most queries finish within a few thousand postings.
   4. If the hot tier cannot fill the page, the search continues into archive slices, newest first. A rare term may have three matches this week. The search service walks back one slice at a time and stops the moment it has a page, so a common term never touches the archive and a rare one touches only as many slices as it needs. That is early termination across tiers, and it only works because tiers are cut by time.
   5. The privacy check hydrates the page from the post store and re-checks every result. It reads each post’s current row: deleted, audience, version and text. A post whose audience narrowed a second ago, or whose author just blocked the viewer, is dropped here even though the index still has the old state. It also re-matches the query against the current text, so an edit that removed a word stops matching at once.
   6. Exact counts for the page come from the engagement counters, and the page returns with a cursor. Counts shown to the user are read live, never from the index. The cursor is (created_at, post_id) of the last result: the next page is a seek to "older than this" in time-ordered postings, so page 50 costs what page 1 costs and posts arriving meanwhile cannot shift it.
3. A goal in the final: likes and searches spike. The scale-breaking case. A million likes a second must reach ranking without rewriting index documents, and thirty thousand people a second search the same word while each must see only what they may see.
   1. Likes pour in at a million a second; one post takes 50 k a second. Each like inserts a (user, post) edge and increments the counter on the same shard, and increments only if the edge was new, so a retry counts once. The viral post’s counter is split into 32 sub-counters summed on read, so one post does not saturate one shard.
   2. The like service writes the post’s bucket only when its count crosses a power of two. Bucket = floor(log2(likes + 1)), one byte. The viral post reaches bucket 17 at 131 k likes and bucket 18 at 262 k, 2.6 s later at 50 k/s, and every later gap is twice as long. Across all posts that is ~50 k bucket writes a second at peak instead of a million.
   3. The change reaches the post’s partition, which overwrites one byte in its bucket array. Buckets, audience and the deleted bit live in per-document arrays beside the postings, not inside them, so this is an in-place write, not a delete and reinsert. The segment’s per-term maximum bucket is raised too, which is what lets Top skip blocks that cannot win.
   4. Thirty thousand people a second search "goal"; the public candidates are computed once and cached. Key (normalised query, sort, language), value the top ~500 public posts with scores, kept ~10 s. Public posts are the only part of a result that is the same for everyone, so they are the only part shared. One request per key refreshes it under a single-flight lock while the rest read the stale copy.
   5. For each viewer, blocked authors are removed and the viewer’s friends-only matches are added. The friends branch is the same query restricted to authors in the viewer’s friend set, which partitions answer quickly because the author check runs before scoring. The two lists are merged by score. The expensive, shared part is cached; the cheap, personal part never is.
   6. Finalists get exact counts, are re-ranked, and pass the privacy check. Buckets are within a factor of two of the truth: good enough to choose the top 100, not good enough to order them, so exact counts decide the final order. Cached public posts go through the privacy check too, because one may have been switched to friends-only after it was cached.
4. The indexer falls behind, then a replica dies. Failures should cost freshness or completeness, never correctness. Index lag means a new post appears late or a deleted one lingers in the index; the final check makes the second harmless.
   1. A bad indexer deploy leaves the hot partitions 90 seconds behind the change stream. Freshness is outside its target: new posts appear 90 s late. Alert on consumer lag in seconds per partition, and on an end-to-end probe that publishes a synthetic only-me post every few seconds per partition and searches for it until it appears.
   2. A post deleted 30 seconds ago is still in the index and matches a query. The tombstone has not been applied, so the partition returns the post. The privacy check reads the post store, sees it deleted, and drops it. Lag costs freshness and a result slot; it never shows something it should not, because the index never has the final word.
   3. A hot replica of partition 7 crashes; the search service routes around it. Nineteen replicas remain, each with ~5 % more load. Each partition request already goes to one replica and is hedged to a second after the 95th-percentile latency, so users notice nothing.
   4. A replacement copies sealed segments from a healthy peer and replays the partition log from their offset. About 60 GB over a 10 Gb/s link is under a minute, and replaying the live segment’s hour or two of posts takes another minute or two. The replica joins rotation only when its lag is under a second. Replaying the whole week from the log would take far longer, which is why sealed segments are copied, not rebuilt.
   5. If a whole partition is slow, the search returns what the others found, flagged as partial. Missing a twelfth of candidates for a few seconds is acceptable; an error page is not. The flag lets the client say results may be incomplete, and keeps the partial answer out of the result cache.
5. Delete, edit and block. The privacy path. Removals are hidden at once by the final check, applied to the index as tombstones within seconds, and physically purged only when segments are merged.
   1. An author deletes a post from last year. The row is marked deleted in the source of truth. From this commit on, the privacy check drops the post from every result, before any index has heard of it. Everything after this keeps pages full and the index honest; hiding the post is already done.
   2. The indexer routes the delete to the archive slice that owns the post and sets its deleted bit. The post id carries its creation time, so routing needs no lookup: time picks the slice, hash(post_id) the partition. Slices are immutable on SSD, but their deleted-document bitmaps are in RAM and writable, so the post stops matching in seconds without rewriting anything.
   3. Another author edits a phone number out of a post; the old version is tombstoned and the new one indexed. If the old version kept matching, searching for the number would find the post and confirm what was removed. The new version goes into a small delta segment in the owning partition, which every query scans in full and merges by created_at, so the post keeps its place in time. The indexer ignores any event older than the version it has applied.
   4. Someone blocks a viewer; that viewer’s next search excludes all of the blocker’s posts. Nothing in the index changes, which is the point: blocks, unfriends and audience lists are read from the graph at query time, so they apply on the next request. Indexing per-viewer permissions would turn one block into a rewrite of every post the blocker ever made.
   5. Later, the builder merges the segments and drops tombstoned documents for good. Hot segments leaving the 7-day window are merged into their week’s slice, and older slices are compacted on a schedule; each merge writes only live documents and folds in the delta segments. Once a merged slice is loaded, its tombstones are released. A slice holding a deletion older than the purge deadline is rewritten even if nothing else would have triggered it.

Deep dives

The theory behind it

• Search, indexing and autocomplete: Inverted indexes, analysis and ranking, prefix search with tries, filtering by permissions, index freshness, and when vector search actually belongs in the answer.
• Authorization and permission systems: Designing who can do what: authentication versus authorization, RBAC, ABAC and relationship-based access control, Google Zanzibar-style permission services, sharing and inheritance, checking permissions fast, filtering lists, and auditing.
• Counting at scale: How to count likes, views, clicks and unique visitors at high volume: exact versus approximate counts, sharded counters, batching through streams, idempotent counting, HyperLogLog for uniques, windowed counts and reconciliation.

Related

• Design Slack
• Design Search Autocomplete
• Design a Project-to-Contractor Matching System
• Design Yelp
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit