How the interviewer opens it
“Design Facebook post search. Users should be able to search by keyword and find relevant, recent posts, while only seeing posts they are allowed to view.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Search behavior
- Visibility rules
- Corpus and retention
- Traffic and read:write mix
- Latency and result size
- Index freshness
- Privacy consistency
- Availability and durability
- Ranking and pagination
- Deployment and boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Search user-authored text posts by keyword and rank by relevance and recency
- Enforce current post visibility, friendship, blocking, and deletion rules
- Make new posts and text changes searchable within seconds
- Paginate ranked, permitted results
Usually out of scope
- Groups and their membership rules
- Image, audio, and video content indexing
- Semantic search and personalized machine-learning ranking
- Building the social graph or post-authoring service
- Global active-active deployment
What interviewers probe
- Permission-correct retrieval despite stale indexes
- The index can say a post is public after it becomes private, and a friendship or block can change visibility without changing the post at all. Filtering after retrieval is necessary but can leave too few results and create heavy authorization traffic.
- Distributed retrieval, ranking, and pagination
- Billions of posts make scans impossible, but blindly querying every shard at peak also becomes expensive. Common terms produce huge match sets, and ranking must balance relevance with recency without sorting every match or ignoring older posts.
- Fresh indexing without resurrection or lost updates
- Search is a derived, asynchronously updated view. Retries, delayed events, source-to-stream gaps, and full reindexing can lose changes or resurrect deleted content unless ordering and recovery are explicit.
Common mistakes
- Treating the inverted index or its audience field as the source of truth for current permissions.
- Ignoring relationship changes because no post-edit event is generated.
- Materializing every post into every friend's search index without accounting for fan-out, revocations, or large audiences.
- Returning a cached result page across viewers, or reusing stale positive authorization decisions.
- Underestimating shard fan-out and permission-check amplification because top-level query QPS looks modest.
- Promising near-real-time indexing without handling dual-write failures, out-of-order updates, deletion tombstones, or reindex catch-up.
The bar by level
- Senior (L5/E5)
- Owns the end-to-end query and mutation paths. Quantifies fan-out and authorization load, handles dynamic relationship revocation, uses bounded refill after filtering, and explains versioned indexing, replay, and search-after pagination.
- Staff (L6+/E6+)
- Makes the privacy guarantee precise across caches, source services, failures, and pagination. Chooses a defensible partitioning and capacity strategy from the workload, controls expensive-query and authorization amplification, and provides a safe online reindex plan. Clearly identifies where stronger consistency costs latency or availability and how the design degrades without leaking posts.