DEV Community: Mehdi Javani

Building Roomzin: Why We Stopped Treating Booking Inventory as a Search Problem

Mehdi Javani — Tue, 21 Jul 2026 20:42:13 +0000

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?

When Kafka Is Too Much and Redis Isn't Enough: Building a Simpler Distributed Job Queue

Mehdi Javani — Tue, 21 Jul 2026 14:22:12 +0000

TL;DR: I built Cue, a Raft-based distributed job queue that handles retries, dead-lettering, and durability without the operational overhead of Kafka or the manual plumbing of Redis. Single binary, zero external dependencies.

The Problem We All Know

You're building internal microservices. You need to dispatch background jobs — send emails, generate reports, process notifications. You need reliability: if a job fails, it should retry. If it keeps failing, you need to know about it.

I've been through this cycle multiple times. Each time, the available options felt like they required either too much operational overhead or too much custom code.

The Database Approach

Most teams start with a PostgreSQL table. It's familiar. But at some point, you need:

Locking mechanisms
Timeout handling
Retry logic with backoff
Cleanup jobs for stuck tasks

Suddenly, your application database becomes a bottleneck, and your job queue competes with your API traffic for resources.

Redis: Fast but Fragile

Redis pub/sub is blazing fast but has zero durability — if a consumer disconnects, messages are gone. Redis Streams improve durability but still require you to build retry and dead-letter handling yourself. Plus, you're now managing Redis persistence, which adds its own operational complexity.

Kafka: Powerful but Overkill

Kafka is optimized for high-throughput event streaming. It's battle-tested and capable. But if your only requirement is durable background jobs, you're paying for:

Partition management
Broker coordination
Consumer group rebalancing
ZooKeeper or KRaft

That's a lot of cognitive load for what should be a simple problem.

RabbitMQ: Mature but Another External Broker

RabbitMQ is a mature, excellent broker. But it's another external system with its own operational model, clustering, and management overhead.

What I Actually Wanted

A durable job queue with:

✅ Jobs that survive restarts
✅ Automatic retries with exponential backoff
✅ Dead letter queue for failed jobs
✅ Simple deployment and scaling
✅ No external dependencies

I didn't need infinite persistence or petabyte-scale throughput. I needed something honest about its limits and simple to operate.

Enter Cue

Cue is a distributed, in-memory job queue built around three core ideas:

1. Consistency Without Complexity

Cue uses the Raft consensus algorithm to keep all cluster nodes in sync. Every command is persisted to a Write-Ahead Log (WAL), so jobs survive restarts. If the leader crashes, a new one is elected automatically.

No ZooKeeper. No external coordination. Just a single binary.

2. Built-in Retry and Failure Handling

Automatic retries with exponential backoff are baked into the system, not an add-on. Failed jobs go to a dead letter queue with configurable retention policies. You don't write custom retry logic or cleanup scripts.

3. Simple Operations

All cluster nodes are identical. No special roles to configure. The system runs as a single binary with zero external dependencies.

The companion gateway, CueProxy, handles external communication — producers submit jobs via HTTP, consumers receive them over WebSockets. It's stateless and scales horizontally without coordination.

Cue won't replace Kafka, RabbitMQ, or Redis. Those tools solve different problems. If your primary requirement is reliable background job execution with automatic retries, dead-letter handling, and minimal operational overhead, Cue is worth evaluating.

Architecture Overview

Communication between cluster nodes uses QUIC with mandatory mTLS. Between proxies and the cluster, it's TLS-secured. Authentication and encryption without complex configuration.

What Cue Does and Doesn’t Guarantee

What Cue Guarantees:

Durability: Jobs survive cluster-wide restarts (WAL persistence)
At-least-once delivery: Duplicates are possible; idempotent consumers required for exactly-once
Automatic retries: Exponential backoff with configurable limits
Dead letter handling: Configurable retention for failed jobs
Backpressure: Bounded queues with clear signaling

What Cue Doesn't Guarantee:

Infinite queue size (in-memory, bounded by RAM)
Historical replay of acknowledged jobs
Exactly-once delivery without client idempotency
Petabyte-scale throughput

Cue is designed for predictable, bounded workloads — not for replacing Kafka as a long-term event store.

Performance

The project includes cue-benchmark that measures two distinct phases:

Ingestion: How fast the system accepts jobs (producer → proxy → cluster)
Dispatch: How fast the system delivers jobs to consumers (cluster → proxy → consumer)

This isn't a synthetic micro-benchmark. It measures what you actually care about in production. You can run it in your own environment to understand throughput limits under your specific conditions.

Note: Early benchmarks show promising results, but performance characteristics depend heavily on your hardware, network, and workload patterns. I'd love community contributions to help optimize and validate performance across different environments.

What You'll Actually Use

Cue Cluster – The core distributed system that holds your jobs, handles retries, and maintains consistency via Raft.

CueProxy – The stateless gateway your applications talk to via HTTP and WebSockets. Handles authentication and passes jobs to the cluster.

cue-benchmark – A helper tool to test performance in your own environment (optional but useful).

Just two main pieces working together. No complex ecosystem to manage.

Community and Contribution

The code is open-source under Apache 2.0. If the design resonates with you, I'd love your feedback:

🐛 Open an issue for bugs or feature requests
💬 Challenge a design decision — I welcome constructive debate
📊 Benchmark it in your own environment and share results
📝 Improve the documentation
🔧 Submit a pull request

Early contributors have the opportunity to help shape where the project goes next. The architecture is flexible enough to evolve based on real-world needs.

Cue is still in its early stages. The core architecture is in place, but there’s plenty of room to improve performance, expand the ecosystem, strengthen testing, and refine the developer experience. If the design resonates with you, I’d love your feedback — whether that’s opening an issue, challenging a design decision, benchmarking it in your own environment, improving the documentation, or submitting a pull request. Early contributors have the opportunity to help shape where the project goes next.

Resources

Main Project: github.com/m-javani/cue
Gateway: github.com/m-javani/cue-proxy
Benchmark: github.com/m-javani/cue-benchmark
Documentation: m-javani.github.io/cue-docs