While building software for booking platforms, I noticed a pattern.
Almost every system eventually evolves into the same architecture.
A cache.
A search layer.
A relational database.
Background synchronization jobs.
Eventually another cache.
Every component solves a real problem, and most of them are excellent technologies.
Yet as traffic grows, performance becomes increasingly difficult to predict. Not because any individual component is slow, but because answering a single booking request requires assembling data from multiple places.
That observation eventually led me to build Roomzin, a dedicated inventory engine for booking platforms.
This article explains why.
A Booking Search Isn't Just a Search
Imagine a traveler searching for a hotel.
The platform has to answer questions like:
- Is the room available for these dates?
- What's the current price?
- Does this rate include breakfast?
- Is free cancellation available?
- Is it within the requested area?
- Does it include the requested amenities?
None of those questions are particularly difficult.
The challenge is that they're often answered by different parts of the system.
Each lookup might be fast.
Putting everything together isn't.
As more features are added, more synchronization is required.
More indexes.
More cache invalidation.
More background processing.
Eventually the architecture spends more effort assembling an answer than finding it.
The Wrong Abstraction
One realization completely changed how I looked at booking platforms.
The bottleneck usually isn't search.
It's reconstruction.
Booking inventory isn't simply text.
It isn't key-value data.
It isn't purely relational either.
Every request combines the same dimensions:
- property
- room type
- date
- pricing
- availability
- policies
- amenities
- location
Those pieces naturally belong together.
Treating them as separate datasets means reconstructing the same answer over and over again.
That's where both latency and operational complexity start to grow.
Asking a Different Question
Instead of asking,
"How can we make our search infrastructure faster?"
I started asking,
"Why are we treating booking inventory as a generic search problem at all?"
Booking inventory has very predictable characteristics.
Most traffic targets the near future.
Availability changes constantly.
Property metadata changes much less frequently.
Queries combine the same dimensions repeatedly.
Those aren't generic search workloads.
They're inventory workloads.
That distinction became the foundation of Roomzin.
Building Roomzin
Rather than building another cache or another search layer, I built an engine specifically for booking inventory.
Instead of storing different parts of the answer in different systems, Roomzin stores inventory around the way booking platforms actually query data:
- Properties
- Room types
- Daily inventory
- Rates
- Policies
The objective wasn't simply lower latency.
It was reducing the amount of work required to answer a request.
Performance became a consequence of that design.
Engineering Decisions
Several implementation choices made that possible.
- Bitmask encoding for amenity and policy filtering
- H3 indexing for constant-time geographic lookups
- Segment-based parallel execution with minimal contention
- QUIC for cluster communication
- Compact binary protocol for SDK communication
- Rust for predictable performance and memory safety
- TiKV's Raft implementation for replication and high availability
None of these techniques are revolutionary on their own.
The interesting part is how they work together around a workload that has very specific access patterns.
Current Results
On a 4-core laptop with 60 million inventory records and 10,000 concurrent connections:
- Median latency: 0.7 ms
- P99 latency: 2.3 ms
- P99.9 latency: 5.1 ms
- Zero errors
Snapshots are created in around 10 ms and restore 60 million records in under 3 seconds.
Rather than asking people to trust these numbers, I made the benchmark tooling publicly available so anyone can reproduce the results using their own hardware.
What I Learned
The biggest lesson wasn't about Rust.
Or distributed systems.
Or optimization.
It was this:
Choosing the right abstraction usually matters more than making the existing abstraction faster.
For years I was thinking about caches, indexes and databases.
Eventually I realized the real optimization was changing the model itself.
Instead of treating booking inventory as something that needed to be reconstructed during every search, I started treating it as a first-class domain.
Everything else followed naturally.
Try It Yourself
If you're interested in the project, everything needed to evaluate it is publicly available.
📖 Documentation
https://m-javani.github.io/roomzin-doc/
🚀 Quickstart (3-node cluster with monitoring)
https://github.com/m-javani/roomzin-quickstart
📊 Benchmark Tool
https://github.com/m-javani/roomzin-bench
The benchmark runs in just a few minutes on your own hardware, so you can verify the results independently.
I'd also love to hear how other teams approach inventory search. Have you built something similar, or do you solve the problem differently?
Top comments (0)