DATABASES Signal 75
Agoda cuts P99 read latency eightfold after moving price cache to DragonflyDB
↗
Agoda migrated its 1.5-TB hotel price cache from 72 SQL Server shards to DragonflyDB to handle growing read and write traffic, reporting an approximately eightfold improvement in P99 read latency.
The shift removes the need for manual shard remapping and predefined hardware upgrades, simplifying scaling operations. Decentralized failure detection lets each application pod switch to a healthy cluster within minutes without a central coordinator, reducing downtime risk. Lower latency and built-in key expiration cut the operational burden of cleaning expired supplier data.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Agoda moved a 1.5 TB volatile price cache from 72-shard SQL Server to DragonflyDB, using staged dual reads and parity validation before full traffic shift.
After migration, DragonflyDB served ~300 k requests/sec at ~8 ms P99 latency, an roughly eightfold latency gain over the previous SQL Server setup.
High availability relies on two DragonflyDB clusters where each pod compares local cache-hit ratios to trigger failover within about two minutes.
THE READ
What the cluster adds up to.
Agoda replaced its tier-one hotel price cache, which lived on a 72-shard Microsoft SQL Server deployment, with DragonflyDB, an in-memory datastore. The cache holds about 1.5 TB of volatile pricing data and was handling roughly 300 000 reads and 1.5 million writes per second. The team chose DragonflyDB after evaluating its shared-nothing, multithreaded architecture, Redis compatibility, cluster-based scaling and built-in key expiration against the actual workload. This evaluation used a production-like read-to-write ratio reproduced with memtier_benchmark.
Migration began with a 1 TB DragonflyDB instance for hot data, but as the dataset approached the 90 % memory-safety threshold the team moved to a three-shard-per-cluster design and expanded to hold the full 1.5 TB. Before shifting customer traffic, Agoda ran dual reads: SQL Server continued serving requests while the price API asynchronously fetched the same data from DragonflyDB. Rather than comparing full payloads, they checked supplier counts and price-data lengths, emitting the results as Prometheus metrics and observed more than 99.9 % parity. An A/B experiment then gradually moved traffic to DragonflyDB over several weeks until 100 % of requests were served by the new store.
After the cutover, DragonflyDB served approximately 300 000 requests per second at around 8 ms P99 read latency, which Agoda reported as an roughly eightfold improvement over the previous SQL Server latency. The new architecture eliminated the need for application-level shard routing, manual shard remapping and predefined hardware increments. Built-in key expiration removed the separate cleanup process that had been required to delete expired supplier data. Overall operational maintenance decreased while read performance improved.
The solution remains bounded by the available memory in the DragonflyDB cluster; if the price cache grows beyond the cluster’s capacity, additional nodes or shards must be added. Failover relies on each pod comparing local cache-hit ratios between two clusters and triggering a switch when a ten-percentage-point divergence persists for five minutes, which may not catch all failure modes. Consequently, the approach works well for the current workload size and pattern but would require re-evaluation if data volume or access patterns change significantly.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER