How Airbnb Rebuilt Search for 8 Million Listings

Lucas: Airbnb runs something like 8 million active listings right now. Every second, travelers are firing off searches - city, date range, price filter, amenity checkboxes - and the system has to return relevant results in under 200 milliseconds. That's the bar. And for years, they hit it with a single massive Elasticsearch cluster.

But by 2023, that setup was starting to crack. Luna: Crack how? Slow queries, or was it more about relevance drift? Lucas: Both, honestly.

The Elasticsearch cluster had grown to over a thousand nodes. Just managing shard rebalancing and index rollovers became a full-time ops job. And because everything lived in one big inverted index, adding new ranking signals - like, say, a guest's preference for superhosts or instant-book listings - meant reindexing billions of documents. That could take days.

Luna: So the classic monolith problem, but at search-engine scale. What did they do? Lucas: They rebuilt the entire search pipeline into three tiers. Tier one is a lightweight inverted index - basically, a bloom filter style prefilter that narrows listings by hard constraints: dates, location bounding box, price range.

That typically cuts the candidate set from 8 million down to maybe 50,000. Luna: Fifty thousand from 8 million - that's a 99 percent reduction before you even hit the ranking layer. Lucas: Exactly. Tier two is a vector similarity search.

Airbnb trained a deep-learning model on past booking patterns and listing features - things like photo aesthetics, neighborhood vibe, even the description's language style. Each listing gets a 128-dimension embedding. The candidate set from tier one gets scored against the query embedding, and the top 500 listings move to tier three. Luna: So the vector layer is doing the heavy lifting on relevance, while the inverted index handles the hard filters.

That's a clean separation of concerns. Lucas: It is. And tier three is a real-time ranking service built in Java - takes those 500 listings and applies a gradient-boosted decision tree model with hundreds of features. Things like the host's response rate, the listing's cancellation policy, whether the guest has booked similar properties before.

That model runs in under 10 milliseconds per query. Luna: Ten milliseconds for 500 listings, with hundreds of features? That's impressive. But how did they actually deploy this without breaking search for users?

Lucas: They ran a shadow comparison for six months. Every live query was sent to both the old Elasticsearch pipeline and the new three-tier pipeline. They logged results but only served the old system's output to users. The engineering team spent months tuning recall and precision metrics until the new pipeline matched or beat the old one on every relevance benchmark they had.

Luna: So when they finally flipped the switch, there was no 'oops, we broke search' moment. Lucas: Exactly. The cutover happened in Q2 2024, and median search latency dropped from about 180 milliseconds to 110 milliseconds. And they also cut infrastructure costs by roughly 30 percent, because the new pipeline uses fewer nodes - the vector tier runs on GPU instances that are expensive per unit but handle way more queries per dollar than the old Elasticsearch cluster.

Luna: That's the dream: better performance, lower cost. But I imagine the migration itself was a huge engineering effort. Were there any nasty surprises? Lucas: A few.

The vector model's embedding service initially had a cold-start problem. When a new listing was created, it wouldn't get an embedding for up to an hour. So during that hour, the listing was essentially invisible to search. Airbnb fixed it by generating a placeholder embedding from the listing's category and location - not perfect, but good enough to surface the listing while the full embedding was computed.

Luna: That makes sense. Better to show a slightly off listing than to hide it entirely. What about the operational side? Running GPU inference in production is not trivial.

Lucas: They built their own model-serving infrastructure on Kubernetes, using NVIDIA's Triton Inference Server. They also implemented a caching layer for frequent query embeddings - if you search 'Paris apartments under $200,' the system caches the embedding for that query and reuses it for a few minutes, which cuts GPU load significantly. Luna: So the architecture is really three separate services talking to each other. That's a lot of moving parts.

How do they handle a failure in one tier? Lucas: Graceful degradation. If the vector tier goes down, they fall back to a simpler ranking model that runs on the inverted index tier. It's not as relevant, but search still works.

If the real-time ranking tier fails, they fall back to the vector similarity scores. The system is designed so that no single tier failure takes down search entirely. Luna: That's a smart way to think about reliability - not just preventing failures, but ensuring the system is useful even when something breaks. Lucas: Right.

And they tested these fallback paths regularly, like chaos engineering style, injecting failures in production during low-traffic hours. Luna: One thing that stands out to me is that Airbnb chose to build custom microservices instead of using a managed vector database like Pinecone or Weaviate. Why go custom? Lucas: Two reasons.

First, at Airbnb's scale - billions of queries a day - the managed solutions would have cost significantly more. They ran a cost analysis and found that building on their own infrastructure was about 40 percent cheaper over a three-year horizon. Second, they wanted full control over the embedding model's versioning and A/B testing pipeline. With a managed service, you're tied to whatever model they support.

Luna: So it's a classic build-versus-buy decision, and at their scale, build wins. Lucas: Exactly. But they didn't build everything from scratch. They used open-source libraries like FAISS for the vector index and Elasticsearch's Lucene for the inverted index tier.

So it's a mix of open-source components with custom glue and orchestration. Luna: Speaking of open source, I've heard that Airbnb contributed some of their work back to the community on this. Lucas: They did. They open-sourced a tool called 'Search Relevance Framework' that allows other teams to define and evaluate relevance metrics in a standardized way.

It's used internally by dozens of teams at Airbnb, and now it's on GitHub. Luna: That's a good example of engineering culture - when you solve a hard problem, you package it up so others don't have to reinvent it. Lucas: Absolutely. And I think the broader lesson here is that search is never a solved problem.

User behavior changes, inventory changes, business priorities shift. Airbnb's new architecture is designed to make it easier to swap out individual components - they've already replaced the ranking model twice since the launch. Luna: So it's not just a one-time migration; it's a platform for continuous improvement. Lucas: Exactly.

And they're already working on adding multi-modal search - letting users upload a photo of a room they like and find similar listings. That would use the same vector tier but with image embeddings instead of text embeddings. Luna: That sounds like a natural next step. Lucas, I want to pivot slightly.

All this talk about building robust infrastructure - it reminds me of how much we rely on listener support to keep this show ad-free and focused on the nitty-gritty. If today's episode was valuable for what you're building, consider tossing a coffee our way. Lucas: Yeah, it's a small gesture that goes a long way. The link is buy me a coffee dot com slash fexingo.

No pressure, but if you found the deep dive useful, that's the spot. Luna: Alright, back to Airbnb. Lucas, you mentioned they're exploring multi-modal search. How does that change the architecture?

Lucas: It adds a new embedding model for images, and a new index for image vectors. But the tiered pipeline stays the same - the inverted index handles filters, the vector tier handles similarity, and the ranking tier handles personalization. The main challenge is that image embeddings are larger - typically 512 dimensions instead of 128 for text - so the vector index needs more memory and compute. Luna: So they might need to invest in more GPU capacity for that use case.

Lucas: Right, but the fallback paths still apply. If the image embedding service is down, they can fall back to text-only search. The system is designed to be resilient to partial failures. Luna: That kind of resilience - thinking through every failure mode - is what separates good engineering from great engineering.

Lucas: Totally. And it's something that comes from experience. The Airbnb team had been running search at scale for over a decade, so they knew exactly where the pain points were. Luna: One last question: for teams considering a similar migration, what's the single most important piece of advice you'd take from Airbnb's playbook?

Lucas: Shadow-compare for longer than you think you need to. Six months felt excessive to some on the team, but it caught dozens of edge cases - like how the new system handled queries with no results, or queries with misspellings, or queries during peak holiday booking periods. Without that long shadow period, they would have shipped a regression. Luna: Patience over speed.

A good lesson for any infrastructure overhaul. Lucas: Exactly. And on that note, I think we've covered the key layers. Thanks for listening, and we'll be back next week with another deep dive into how the internet's biggest services actually work.