Agoda has achieved an approximately eightfold improvement in P99 read latency after moving its tier-one hotel Price Cache from a 72-shard Microsoft SQL Server deployment to DragonflyDB, an in-memory datastore. The migration, detailed in a blog post published in September 2026, addressed mounting read and write volumes while simplifying scaling for the travel platform's pricing infrastructure. DragonflyDB now serves about 300,000 requests per second at around 8 milliseconds P99 latency, compared to the slower performance under the previous SQL Server architecture.
The Price Cache holds roughly 1.5 TB of volatile pricing data and processes approximately 300,000 reads and 1.5 million writes per second. Agoda's earlier setup relied on application-level shard routing across 72 SQL Server shards, which required predefined hardware increases and manual shard remapping plus data migration whenever scaling became necessary. After the team doubled hardware capacity in early 2024, they were approaching the limits again within a year. The expanding workload also demanded a separate cleanup process to delete expired supplier data. The final DragonflyDB cluster handled approximately 1.6 million writes per second at around 10 milliseconds P99 latency.
Clarkson Chang, lead engineer at Agoda, noted the problem space: "It became clear that continuing to add resources to SQL Server was not a viable or cost-effective long-term strategy." The team evaluated DragonflyDB against the actual workload rather than depending solely on published benchmarks, according to the report. Its shared-nothing, multithreaded architecture, Redis compatibility, cluster-based scaling, and built-in key expiration aligned with the Price Cache workload, which depends heavily on MGET and SET operations. Agoda first used memtier_benchmark to replicate a production-like 1:6 read-to-write ratio and average 10-key MGET operations.
The migration proceeded deliberately. Agoda initially deployed a 1 TB DragonflyDB instance for hot data, but organic growth pushed the dataset toward the 90% memory-safety threshold, prompting the team to adopt a three-shard-per-cluster design and expand DragonflyDB to accommodate the complete 1.5 TB dataset. Before shifting customer traffic, Agoda introduced dual reads: SQL Server continued serving requests while the Price API asynchronously retrieved corresponding data from DragonflyDB. Instead of comparing entire price payloads, the team checked supplier counts and price-data lengths, emitting the results as Prometheus metrics; both dimensions reached more than 99.9% parity. Agoda then used an A/B experiment to gradually redirect customer traffic to DragonflyDB, and after several weeks, 100% of traffic had migrated and the SQL Server read and write paths were retired.
The final architectural change tackled failure handling. Two DragonflyDB clusters, A and B, provide high availability. Rather than depending on a central coordinator, each application pod independently compares the clusters' cache-hit ratios using five minutes of local observations. A statistically significant 10-percentage-point divergence marks a cluster unreadable, while recovery requires the difference to fall within three percentage points. During an outage simulation, roughly 40 application pods detected the failure and entered failover within approximately two minutes without manual intervention. Agoda paired the datastore migration with production parity checks, controlled traffic migration, explicit cache-warming behavior, and decentralized failure detection, yielding not only lower latency but also a less rigid scaling model and reduced operational maintenance around stale data and failover. The company's incremental approach—benchmarking against real workloads, dual-reading for validation, and A/B testing traffic shifts—offers a blueprint for teams weighing similar infrastructure rewrites. Organizations managing high-throughput caches may face a choice between vertical scaling within familiar relational systems and horizontal scaling through purpose-built datastores, each carrying distinct trade-offs in operational complexity and long-term flexibility.