Search System Design Case Studies: Discord, GitHub, LinkedIn, Uber, Pinterest and More

GitHub's code search corpus holds 115 TB of code. eBay matches queries against 1.7 billion live listings and answers 95% of requests in under 25 ms. Neither started there. Both started with a search box and a reasonable first design, then grew until that design broke. This is a casebook of those moments: what each company faced, what it picked, and what it learned.

01How to read these cards

Think of this page as a doctor's casebook: symptoms, treatment, outcome. One case is a story. Twenty side by side show you the pattern, and the pattern is what you take into an interview.

Every card has the same five lines:

• Faced: the problem, with numbers from the company's own post.
• Chose: the design they picked.
• Learned: results, surprises and regrets.
• Read it: the original post.
• Maps to: the blog in this series that explains the idea underneath.

The cards fall into eight themes. Here is the map before we start.

02Theme 1: the storage under the search box

Before anything is searchable, the data has to live somewhere fast and safe. These three stories sit underneath search.

Discord: storing trillions of messages

• Faced: hot partitions on Cassandra, where one busy channel slowed its neighbours. By early 2022 the cluster had 177 nodes.
• Chose: Rust "data services" in front of the database that coalesce duplicate reads and route by channel ID with consistent hashing, then a migration to ScyllaDB.
• Learned: 72 nodes after the move. Historical-message fetch p99 went from 40-125 ms to 15 ms, and insert p99 from 5-70 ms to a steady 5 ms.
• Read it: How Discord Stores Trillions of Messages
• Maps to: Reads and writes

Discord: the "super-disk"

• Faced: network-attached persistent disks added milliseconds to every read. Local NVMe SSDs were fast, but their data doesn't survive the machine.
• Chose: a Linux md RAID1 mirror of a local SSD and a persistent disk, with the persistent disk marked "write-mostly" so reads come from the SSD.
• Learned: SSD-speed reads with durable writes. The price is extra complexity, including handling bad sectors on the local SSD.
• Read it: How Discord Supercharges Network Disks for Extreme Low Latency
• Maps to: Disk I/O and durability

Uber: H3, a hexagon grid for the planet

• Faced: pricing and dispatch must group a constant stream of locations by area.
• Chose: H3, a hierarchical grid of hexagons. Surge pricing is computed per hexagon.
• Learned: hexagons reduce quantization error for people on the move. The catch: a hexagon "cannot be perfectly subdivided into seven hexagons", so child cells only roughly fit inside their parent.
• Read it: H3: Uber's Hexagonal Hierarchical Spatial Index
• Maps to: Storage data structures, Types of search (geo)

03Theme 2: scaling the Elasticsearch you already run

Most teams start on Elasticsearch, and most should. Discord's two posts show how far you can take it.

Discord, part 1: indexing billions of messages

• Faced: search had to cost less than storing the messages, heal itself with no dedicated ops team, and index lazily. Managed SaaS would have "blown our budget".
• Chose: Elasticsearch (no ZooKeeper, automatic rebalancing, and the team knew it). The app shards across many small clusters, using a shard map in Cassandra cached in Redis. Messages are bulk-indexed, with 1 shard, 1 replica and a 60-minute refresh.
• Learned: bulk beats real-time, because people mostly search older messages. Small clusters keep the blast radius small, and a lost one can be re-indexed lazily.
• Read it: Indexing Billions of Messages
• Maps to: Elasticsearch

Discord, part 2: indexing trillions

• Faced: clusters past 200 nodes, master nodes running out of memory, and fragile rolling restarts.
• Chose: Elasticsearch on Kubernetes, with smaller clusters grouped into "cells" with dedicated master, ingest and data nodes. Indices stay within Elastic's 200M messages / 50 GB guideline. The biggest servers, near Lucene's ~2 billion document limit, get multi-shard indices.
• Learned: a single primary shard is fastest for most tenants, and cluster state doesn't scale with node count.
• Read it: Indexing Trillions of Messages
• Maps to: Elasticsearch, Storage data structures

Here is the shape Discord ended up with. Notice that routing lives in the application, not inside one giant cluster.

Netflix: one index per asset type

• Faced: Cassandra is the source of truth and Elasticsearch handles discovery, with more than 7 TB indexed. One index per asset type caused mapping problems as types multiplied.
• Chose and learned: a redesigned index strategy. We couldn't verify the details, so read the post for them.
• Read it: Indexing Strategy in AMP
• Maps to: Elasticsearch (mappings)

04Theme 3: bend Lucene, or start over

Two famous rebuilds, two opposite answers. LinkedIn kept Lucene and threw away everything around it. GitHub threw away all of it, because code isn't text in the way Lucene expects.

LinkedIn: Galene

• Faced: Lucene plus many home-grown layers (Sensei, Zoie, Bobo, Cleo and more) had "hit a wall". Rebuilds were very hard and scoring was rigid.
• Chose: Galene, which keeps Lucene only as the index layer. Indexes are built offline in map-reduce jobs, and scoring is a separate plugin step after retrieval.
• Learned: weekly rebuilds forced a faster release cycle, and splitting infrastructure from relevance freed relevance engineers from writing RPC code.
• Read it: Did you mean "Galene"?
• Maps to: Choosing a search engine, How search engines work

GitHub: Blackbird code search

• Faced: text search is poor for code, which needs punctuation, no stemming and regex. The first Elasticsearch setup took months to index about 8 million repos; there are now over 200 million.
• Chose: Blackbird, a Rust engine with ngram inverted indexes. Shards are keyed by Git blob ID, which spreads data evenly and removes duplicates.
• Learned: 115 TB of code across 45 million repos shrinks to about 28 TB unique. Shard p99 is around 100 ms, and a full re-index takes about 18 hours.
• Read it: The technology behind GitHub's new code search
• Maps to: Storage data structures