Agoda Cuts Read Latency Eightfold by Migrating Price Cache from SQL Server to DragonflyDB

Agoda has completed a major migration of its tier-one price cache, moving away from a sprawling 72-shard Microsoft SQL Server architecture to DragonflyDB, an in-memory datastore. The shift addresses escalating read and write demands while streamlining the platform's scaling model.

The Problem at Scale#

The old system maintained roughly 1.5 TB of volatile hotel pricing data, absorbing around 300,000 reads and 1.5 million writes per second. However, the SQL Server deployment required manual application-layer shard routing and rigid, predefined capacity increments. When Agoda doubled its hardware in early 2024, the infrastructure began hitting limits again within a single year. Managing expired supplier data also demanded a separate cleanup pipeline.

Clarkson Chang, a lead engineer at Agoda, summarized the bottleneck: continuing to expand the SQL Server setup was neither sustainable nor cost-effective long term.

Evaluating and Testing DragonflyDB#

Rather than relying solely on vendor benchmarks, Agoda stress-tested DragonflyDB against a realistic workload model. The in-memory datastore's architecture—which emphasizes shared-nothing, multithreaded processing, Redis compatibility, cluster-based scaling, and automatic key expiration—aligned closely with the cache's needs. The team used memtier_benchmark to simulate production traffic patterns, including a 1:6 read-to-write ratio and multi-key GET operations averaging 10 keys.

Rolling Out the Migration#

Agoda adopted a gradual, risk-aware approach. Initially, a single 1 TB DragonflyDB instance handled hot data, but organic growth pushed the dataset toward the 90% memory-safety threshold. The team then shifted to a three-shard-per-cluster design and scaled DragonflyDB to accommodate the full 1.5 TB. The resulting cluster achieved approximately 1.6 million writes per second at roughly 10 milliseconds P99 latency—a stark contrast to the earlier eightfold improvement in read latency.

Before switching live traffic, Agoda introduced dual reads: SQL Server continued serving production requests while the Price API fetched corresponding data from DragonflyDB asynchronously. Rather than comparing entire price payloads, the team validated parity by checking supplier counts and price-data lengths, logging results to Prometheus. Both metrics achieved over 99.9% agreement.