Design Post Search
Design a social media post search system that allows users to create posts and search through existing posts using boolean operators (AND/OR) without relying on built-in search engines like Elasticsearch.
Asked at:
Meta
Amazon
Post Search is a keyword search feature for short social posts where users create text updates and quickly find relevant content using simple boolean operators like AND and OR. Think of searching Facebook status updates or community posts by words and phrases, and sorting results by recency or engagement. Interviewers ask this because it forces you to design the core of a search system without relying on Elasticsearch or Solr. They want to see if you can build an inverted index, plan for boolean query evaluation, handle hot keys, meet low-latency SLAs, and balance freshness against write amplification. The problem is intentionally focused so you can reason about ingestion, indexing, query planning, caching, and pagination under realistic load.
Hello Interview Problem Breakdown
Design FB Post Search
System design answer key for designing a social media post search feature like Facebook's, built by FAANG managers and staff engineers.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to create text posts that become searchable shortly after creation.
Users should be able to search posts by keywords using boolean operators AND and OR.
Users should be able to sort search results by recency or by like count.
Users should be able to paginate through search results deterministically without duplicates.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
This is the core of the interview: you need an information retrieval plan that scales. Interviewers want to see inverted index fundamentals, sound tokenization, and a query execution strategy that can run fast and cheaply. - Design an inverted index keyed by normalized tokens mapping to compressed posting lists of postIds; for AND intersect lists, for OR union and dedupe; normalize queries (lowercase, Unicode handling, stop words/stemming if allowed) to reduce index size and increase cache hits. - Support sorting by storing per-posting metadata (timestamp, like count sketch) or maintaining multiple list orders (e.g., recency heads per token); use early termination and capped lists to limit work. - Partition by token hash and use scatter–gather so intersections/unions happen close to data; merge partial results with a global tiebreaker (score, timestamp, postId) for stable ordering.
Search is read-heavy and latency-sensitive at companies like Meta. You’ll need a plan for hot data in memory, result caching, and a freshness SLA that keeps the system stable during spikes. - Keep hot posting-list heads in-memory (e.g., Redis) and cache normalized query results with short TTLs; precompute per-token top-K heads for recency and engagement to accelerate most queries. - Embrace eventual consistency: index via an async pipeline and target freshness of 30–60 seconds; measure and limit indexer lag, and expose graceful degradation if behind. - Improve tail latency with time-range filters (e.g., last N days), per-clause caps, and early stopping; paginate using a cursor that encodes the last seen (score, timestamp, postId) to avoid re-sorting large sets.
Write amplification can crush your cluster if every post and every like triggers many index updates. Interviewers expect isolation of the write path, batching, and idempotent processing to keep up under load. - Decouple writes with a durable log (e.g., Kafka) and stateless indexer workers; shard by token hash so multiple workers update different partitions concurrently; make updates idempotent to support replays. - Batch like updates and use approximate counters (e.g., powers-of-2 milestones) to reduce index churn; re-rank precisely at read time within a small candidate set. - Protect hot shards with backpressure and autoscaling; monitor queue lag and per-partition throughput to detect and mitigate hotspots early.
Hot keywords (e.g., "covid", "football") and broad OR queries can explode result sets and blow up latency. You need strategies to cap work, localize computation, and return useful partial results. - Identify hot tokens and maintain small capped heads per sort (recency, likes); spill long tails to colder storage and only fetch deeper segments on demand with strict time/size limits. - Push compute to shards: intersect/union on the shard and return limited top-K per shard; perform a final bounded merge at the aggregator with timeouts and partial-result tolerances. - Add server-side guards: per-clause caps, mandatory time windows, and query normalization; log heavy queries and precompute caches for recurring patterns.
Relevant Patterns
Relevant patterns that you should know for this question
Search is dominated by reads; keeping hot posting-list heads in memory, caching normalized query results, and precomputing small per-token heads for different sorts are critical to keep p95 under 200–300 ms.
Post creation and like events create heavy write amplification into the index. A log-based pipeline, partitioned index shards, batching, and idempotent workers let the system absorb spikes without falling behind.
Hot tokens and viral posts create hot shards and keys. Sharding by token hash, scatter–gather query execution, capping posting lists, and backpressure are necessary to avoid hotspots and tail latency blowups.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL works well as the system of record for posts and user interactions, offering strong consistency and secondary indexes for metadata, while the search index lives outside as a purpose-built inverted index.
Similar Problems to Practice
Related problems to practice for this question
It is the same core problem: building boolean keyword search over social posts with sorting and near-real-time indexing, plus handling hot keys and stable pagination.
Both require creating and serving an inverted index, dealing with tokenization, posting lists, and efficient query evaluation across many shards.
Both rely on high-throughput event ingestion with a durable log, idempotent consumers, and approximate counters to keep write amplification under control before read-time ranking.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Relying on Elasticsearch/Solr despite the constraint
This ignores the explicit requirement and prevents you from demonstrating core IR design skills. It signals you may not understand how inverted indexes, postings, and boolean evaluation work.
Using SQL LIKE scans or full-table scans for keyword search
Pattern-matching scans do not scale to millions of posts and cannot support low-latency boolean AND/OR. You’ll blow through CPU and I/O budgets and fail latency targets.
Ignoring hot-key contention and unbounded posting lists
Without sharding, capping, and scatter–gather, hot tokens and wide OR queries will overload single nodes, create long tails, and cause cascading timeouts during spikes.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late September, 2025
Meta
Senior
Mid September, 2025
Meta
Staff
Mid August, 2025
Meta
Principal
Your account is free and you can post anonymously if you choose.