How Roomzin achieves sub-millisecond searches at scale—without magic
Roomzin's speed stems from a unique combination:
innovative architectural patterns, intentional trade-offs, and a domain-specific design.
Unlike generic systems, it's built exclusively for booking platforms—eliminating unnecessary complexity while optimizing for real-world performance.
High-performance patterns enabling microsecond response times
All booking terms—like cancellation policies and included amenities—are efficiently stored as a 24-bit feature set.
bitwise AND (single CPU cycle)
All strings are converted to numeric IDs at ingest time:
bit position 2
16-bit ID: 142
Uses Uber's H3 library for O(1) radius searches instead of O(log n) R-tree lookups.
Data is partitioned into segments (e.g., "paris_north", "paris_south") that operate independently.
Each segment has its own processing queue
Paris' 1,800 hotels → 5 segments = 5x CPU utilization
No cross-segment locking or coordination
Decoupled read and write channels with priority queuing ensure writes never starve.
Modern transport protocol replacing TCP for secure, multiplexed node-to-node communication.
Zero-parsing wire format (not HTTP/JSON) optimized for microsecond latencies.
Complete data replication across all nodes with no sharding overhead.
No cross-node joins required
Consistent 1-2ms reads on follower nodes
All nodes contain complete dataset
Snapshots use Rust's atomic references and copy-on-write for zero-downtime persistence.
Max 24 booking terms—like cancellation policies and included amenities
Bitmask encoding enables SIMD and single-cycle filtering
In practice, this cap is much higher than real-life needs of booking platforms use cases.
Battle-tested consensus from CNCF-graduated TiKV project.
Custom-configured async runtime for high-throughput TCP.
Intelligent workload distribution across CPU cores.
Modern transport protocol with built-in encryption.
Roomzin integrates these battle-tested components into a cohesive system optimized for booking workloads.
TiKV Raft ensures data consistency across cluster
Tokio + QUIC handle 10k+ connections with minimal latency
Adaptive partitioning delivers predictable performance
Flexible Processor Allocation
Each logical processor can handle multiple segments if needed, or large segments can be split across multiple processors
CPU-Aware Scheduling
Processors are pinned to CPU cores for cache efficiency, but multiple processors can share a core when necessary
Automatic Load Balancing
The system intelligently partitions data within segments to ensure even distribution across available processors
Key Insight: Roomzin adapts to your hardware
Whether you have 4 cores or 64 cores, the system automatically optimizes processor allocation for maximum throughput
Topology-Aware Routing
SDKs automatically discover cluster layout and route requests to optimal nodes
Automatic Failover
Leader election? Node down? SDKs reroute instantly—no code changes needed
Built-in Load Balancing
Reads go to fastest follower, writes to leader—all handled automatically
Unlike traditional request/response blocking, Roomzin uses fully decoupled channels for maximum throughput.
Inefficient: Connection idle while processing
Efficient: Full pipeline utilization
How It Works
Client-side: Each request gets a unique correlation ID. SDK maintains request/response mapping.
Server-side: Separate threads handle requests and responses. No blocking, pure async processing.
Result: 10k RPS with predictable latency, even with mixed request sizes
In large booking platforms, data is sharded by region or zone. Each shard runs its own Roomzin cluster.
Shard = Independent Cluster
Each geographical region runs its own Roomzin cluster with full HA. SDKs only need to know their shard's nodes.
No Cross-Shard Communication
Like Redis deployments, each shard is isolated. Traffic stays within the shard for lowest latency.
Every 100ms faster = 1-3% more conversions
Roomzin cuts 150ms → 2ms = potential 4-12% revenue lift
Zero overbooking during flash sales
Strong consistency prevents double bookings under load
Handle Black Friday traffic spikes
Predictable performance at 25k RPS per shard
Eliminate cache debugging
No more TTL mismatches, invalidation storms, or cache stampedes
70% less infrastructure
Replace Redis cluster + DB tuning + application logic with one binary
Developer time reallocated
Instead of cache layer maintenance, build new features
The best way to understand Roomzin is to run your own benchmarks. Download the benchmark tool and test against your real workload.