Agoda has migrated its tier-one hotel Price Cache from a 72-shard Microsoft SQL Server deployment to DragonflyDB, an in-memory datastore, to address growing read and write volumes and simplify scaling. The cache stores about 1.5 TB of volatile pricing data and handles roughly 300,000 reads and 1.5 million writes per second. Following the migration, Agoda reported an approximately eightfold improvement in P99 read latency, with DragonflyDB serving about 300,000 requests per second at around 8 milliseconds P99 latency.
Agoda’s previous architecture required application-level shard routing across 72 SQL Server shards. Scaling required predefined hardware increments and manual shard remapping and data migration. After doubling hardware capacity in early 2024, the team was approaching the limits again within a year. The growing workload also required a separate cleanup process to remove expired supplier data.
Clarkson Chang, lead engineer at Agoda, highlighted 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 workload rather than relying solely on published benchmarks. Its shared-nothing, multithreaded architecture, Redis compatibility, cluster-based scaling, and built-in key expiration matched the Price Cache workload, which relies heavily on MGET and SET. Agoda first used memtier_benchmark to reproduce a production-like 1:6 read-to-write ratio and average 10-key MGET operations.
DragonflyDB in cluster mode (Source: Agoda Blog Post)
The migration was deliberately incremental. Agoda initially deployed a 1 TB DragonflyDB instance for hot data, but organic growth pushed the dataset toward the 90% memory-safety threshold. The team subsequently moved to a three-shard-per-cluster design and expanded DragonflyDB to hold the complete 1.5 TB dataset. The resulting cluster processed approximately 1.6 million writes per second at around 10 milliseconds P99 latency.
Before shifting customer traffic, Agoda introduced dual reads. SQL Server continued serving requests while the Price API asynchronously retrieved corresponding data from DragonflyDB. Rather than comparing complete price payloads, the team checked supplier counts and price-data lengths, emitting the results as Prometheus metrics. Both dimensions achieved more than 99.9% parity.
Agoda then used an A/B experiment to gradually move customer traffic to DragonflyDB. After several weeks, 100% of traffic had migrated, and the SQL Server read and write paths were retired.
The final architectural change addressed failure handling. Two DragonflyDB clusters, A and B, provide high availability. Instead of relying 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.
Cache Hit Ratio tracking during maintenance of the B-cluster (Source: Agoda Blog Post)
Agoda coupled the datastore migration with production parity checks, controlled traffic migration, explicit cache-warming behavior, and decentralized failure detection. The result was not only lower latency but also a less rigid scaling model and reduced operational maintenance around stale data and failover.