Agoda Cut Latency 8x With a Database Switch

Travel giant Agoda replaced a 72-server SQL database with two DragonflyDB clusters, cutting data access latency for its price cache by 8x.

Online travel company Agoda has successfully modernized a core piece of its infrastructure, replacing a massive, 72-instance SQL Server database with just two DragonflyDB clusters. According to a report from InfoQ, the migration involved Agoda's 1.5 terabyte hotel Price Cache, a critical system responsible for serving real-time pricing data to millions of users. The previous setup, which relied on a technique called sharding to split the data across 72 separate servers, was becoming difficult to manage as read and write volumes continued to grow. The result of the migration is a dramatic performance improvement: Agoda reported an eightfold reduction in P99 read latency. This means that the slowest 1% of requests to fetch pricing data are now eight times faster, a significant enhancement to the user experience and a testament to the efficiency of the new system.

Executing such a change on a live, business-critical system required a meticulous and carefully planned migration strategy to avoid downtime and data loss. Agoda's engineering team did not simply switch from the old system to the new one overnight. Instead, they employed a multi-phased approach designed to de-risk the entire process. The first stage involved implementing “dual reads,” where the application would request data from both the old SQL Server cache and the new DragonflyDB cache simultaneously. This allowed the team to run the new system in a production environment without actually serving user traffic from it. The next crucial step was “parity validation,” where they constantly compared the data returned from both systems to ensure the new DragonflyDB cache was accurate and consistent with the SQL Server source of truth. Once confident in the new system's stability and correctness, Agoda began a “gradual traffic shift,” slowly routing a small percentage of live read traffic to DragonflyDB, carefully monitoring performance metrics and error rates before increasing the load. This methodical rollout was supported by a decentralized failover mechanism to ensure high availability throughout the transition.

The challenges Agoda faced are common across the technology industry, especially for companies operating at a large scale. For many years, the standard way to scale a traditional relational database was through manual sharding, as Agoda had done with SQL Server. While this approach can extend the life of a system, it introduces immense operational complexity. Managing, monitoring, backing up, and ensuring consistency across dozens or even hundreds of individual database shards becomes a significant engineering burden that can slow down development and increase the risk of outages. Agoda's migration is a clear example of a company hitting the ceiling of this architectural pattern. The move to a modern, in-memory data store like DragonflyDB represents a broader trend. These newer systems are purpose-built for high-throughput, low-latency workloads, offering a more streamlined and often more performant alternative to the complex, manually sharded architectures of the past. They are designed to scale horizontally with less operational overhead, making them an attractive option for performance-critical applications like caching, real-time analytics, and message queues.

For CTOs, architects, and developers, the Agoda case study offers several practical takeaways. First, it demonstrates that modernizing a core data layer, while a significant undertaking, can deliver transformative results that directly benefit the business. An 8x reduction in latency is not just an abstract technical achievement; it translates to a faster, more responsive application for customers, which can improve engagement and conversion rates. Second, Agoda's migration strategy serves as a valuable blueprint for other organizations planning to replace a critical system. The principles of dual reads, data validation, and gradual, controlled traffic shifting are essential for minimizing risk and ensuring a smooth transition. Finally, the move from 72 servers to just two highlights the potential for simplification and consolidation. By choosing a technology better suited to the problem, companies can not only boost performance but also reduce architectural complexity, freeing up engineering resources to focus on building new features rather than maintaining a cumbersome legacy system.

This case study shows how modern in-memory databases like DragonflyDB can solve significant scaling challenges faced by legacy relational systems. For engineers, it's a real-world blueprint for migrating critical, high-traffic services with minimal downtime and validating the performance gains of newer data stores.

Agoda's migration demonstrates a path to dramatically improving application performance and potentially lowering infrastructure costs by consolidating a large, complex system. This enhances user experience, which can directly impact bookings and revenue, while also simplifying operational overhead for the engineering team.