Skip to content Skip to footer

CASE STUDY

Zavia Travel

The Property Management Company focus on Hotel Management Software in the Cloud for small and large hotels, Zavia Distribute the hotel inventory in all online channels and automate the hotel management process in the operational, administrative, and commercial areas.


Developed for the continuous improvement and automation of the hotel business process through reservation engines, connectivity with channel managers, payment gateways, real-time information with automated reports and more.

Proposed Solution

Simplified view of the process

Creating the Aurora database in the same region as the EC2 instances that will use it offers several advantages in terms of high availability, scalability, automated backups, and performance insights, position it as a robust solution that can significantly enhance Zavia Travel's database performance, reliability, and overall operational efficiency compared to their existing MySQL database.

MAIN

Technological challenges

Zavia manages its own AWS console; their current architecture has a group of EC2 applications and batch process that consume a RDS MySQL database.

There are some occasional crashes but during high season Zavia experiments a high number of requests, and the number of crashes and downtime increases as well. The EC2 instances and the database are in different regions, which also causes latency.

They know that the cause of the problems is most likely the database, so they want us to propose a migration plan to a new database that solves this problem, but before we do the migration in production environment, we must present evidence that the migration is going to work.

The challenge presented by Zavia Travel revolves around improving the performance and reliability of their architecture due to occasional crashes and downtime, particularly during high-demand periods. The goal is to address these issues by migrating their existing RDS MySQL database to a new solution that can handle the increased load without compromising service quality. The proposed solution outlines a comprehensive migration plan, encompassing testing, validation, and eventual deployment.

aws logo

HOW

AWS was used as part of the solution

To begin with a dedicated “Test” environment was established to validate the migration process and ensure that all processes continue to function correctly. This environment serves not only for migration validation but also for future architectural changes.

The migration targets an RDS Aurora database, which offers all the above benefits compared to the existing RDS MySQL database, which is configured with both a write node and a read node. This architecture allows for optimized read and write operations and, if needed, auto scale more read nodes.

All existing AWS resources from the original architecture are replicated in the testing environments, ensuring a comprehensive testing ground that mirrors production conditions.

AWS Organizations are utilized for better resource management, access control, and governance across different environments.

An EC2 instance is employed as a bastion host for backup and restoration purposes. This instance helps facilitate the migration process by creating a backup of the source MySQL database and restoring it to the Aurora database.

EC2 instances that perform write operations consume the write endpoint from the Aurora write node, while instances needing read access utilize the read endpoint from the Aurora read nodes (in the end 2 read nodes where always active).

If the migration proves successful in the test stage, the solution can be deployed to the production environment. This phased approach minimizes risks and ensures a smooth transition.

Main

Results

  1. Estimated savings of USD 360.00 annually for cross-region transfer.
  2. Migration from Amazon RDS to Amazon Aurora estimated savings of USD 3,200 annually by performing the migration, there used to be a m5.2xlarge database ($0.6840 on demand), now an Aurora with t4g.large family (read and write, $0.1153 for 1 Yr Reserved), by changing from one database engine to another, there was a significant reduction in cost, as well as an increment in performance.
  3. It was validated that DB backups are correctly scheduled, something that did not exist before.
  4. Zavia did not possess a testing environment, because of our testing, there is now a testing environment that can be utilized for new developments or other migrations.
  5. Autoscaling allowed the application to scale up or down its resources dynamically based on changes in demand, so that the system can continue to perform optimally even during peak loads or sudden spikes in traffic giving Zavia high availability of a 99.99%, in other words no more downtime because of crashes.

We envision the future, by creating smart tech solutions

Contact Us

Cloudgenia, Inc.
13359 N Hwy, 183 Austin
#406-1015, Austin, TX  78750

Social Media
Our Brands
Logo Capibara
Newsletter
Contact Us

Cloudgenia, Inc.
13359 N Hwy, 183 Austin
#406-1015, Austin, TX  78750

Social Media
Our Brands
Logo Capibara
Newsletter
Our Brands
Logo Financial Solutions White
Logo Capibara

All Right Reserved by Cloudgenia Inc. Copyright ©