Agoda Migrates Hotel Price Cache from SQL Server to DragonflyDB for Performance and Scaling

Migration to DragonflyDB

Agoda has moved its tier-one hotel Price Cache from a 72-shard Microsoft SQL Server deployment to DragonflyDB. This change addresses the growing volume of reads and writes, and aims to simplify the scaling process for the cache, which stores about 1.5 TB of volatile pricing data.

Performance Improvements

Following the migration, Agoda reported an approximately eightfold improvement in P99 read latency. DragonflyDB now serves about 300,000 requests per second at around 8 milliseconds P99 latency. The system also processes approximately 1.6 million writes per second at around 10 milliseconds P99 latency.

Challenges with Previous Architecture

Agoda's prior architecture required application-level shard routing across 72 SQL Server shards. Scaling involved predefined hardware increments and manual shard remapping and data migration. The team found that continuously adding resources to SQL Server was not a viable long-term strategy due to cost and operational complexity.

Evaluation and Implementation

Agoda evaluated DragonflyDB based on its shared-nothing, multithreaded architecture, Redis compatibility, cluster-based scaling, and built-in key expiration, which aligned with the Price Cache workload's heavy reliance on MGET and SET operations. The migration was incremental, starting with a 1 TB DragonflyDB instance and eventually expanding to a three-shard-per-cluster design to hold the full 1.5 TB dataset.

Before fully shifting customer traffic, Agoda implemented dual reads, where SQL Server continued to serve requests while the Price API asynchronously retrieved data from DragonflyDB. This allowed for parity checks, with both supplier counts and price-data lengths achieving over 99.9% parity. Customer traffic was then gradually moved to DragonflyDB using an A/B experiment.