AWS Architecture Blog
ITS adopts microservices architecture for improved air travel search engine
Internet Travel Solutions, LLC (ITS) is a travel management company that develops and maintains smart products and services for the corporate, commercial, and cargo sectors. ITS streamlines travel bookings for companies of any size around the world. It provides an intuitive consumer site with an integrated view of your travel and expenses.
ITS had been using monolithic architectures to host travel applications for years. As demand grew, applications became more complex, difficult to scale, and challenging to update over time. This slowed down deployment cycles.
In this blog post, we will explore how ITS improved speed to market, business agility, and performance, by modernizing their air travel search engine. We’ll show how they refactored their monolith application into microservices, using services such as Amazon Elastic Container Service (ECS), Amazon ElastiCache (Redis OSS), and AWS Systems Manager.
Building a microservices-based air travel search engine
Typically, when a customer accesses the search widget on the consumer site, they select their origin, destination, and travel dates. Then, flights matching these search criteria are displayed. Data is retrieved from the backend database, and multiple calls are made to the Global Distribution System and external partner’s APIs, which typically takes 10-15 seconds. ITS then uses proprietary logic combined with business policies to curate the best results for the user. The existing monolith system worked well for normal workloads. However, when the number of concurrent user requests increased, overall performance of the application degraded.
In order to enhance the user experience, significantly accelerate search speed, and advance ITS’ modernization initiative, ITS chose to restructure their air travel application into microservices. The key goals in rearchitecting the application are:
- To break down search components into logical units
- To reduce database load by serving transient requests through memory-based storage
- To decrease application logic processing on ITS’ side to under 3 seconds
Overview of the solution
To begin, we decompose our air travel search engine into microservices (for example, search, list, PriceGraph, and more). Next, we containerize the application to simplify and optimize system utilization by running these microservices using AWS Fargate, a serverless compute option on Amazon ECS.
Every search call processes about 30-60 MB of data in varying formats from different data stores. We use a new JSON-based data format to streamline varying data formats and store this data in Amazon ElastiCache (Redis OSS), an in-memory data store that provides sub-millisecond latency and data structure flexibility. Additionally, some of the static data used by our air travel search application was moved to Amazon DynamoDB for faster retrieval speeds.
ITS’ modernized architecture has several benefits beyond reducing operational expenses (OpEx). Some of these advantages include:
- Agility. This architecture streamlines development, testing, and deploying changes on individual components, leading to faster iterations and shorter time-to-market (TTM).
- Scalability. The managed scaling feature of AWS Fargate eliminates the need to worry about cluster autoscaling when setting up capacity providers. Amazon ECS actively oversees the task lifecycle and health status, responding to unexpected occurrences like crashes or freezes by initiating tasks as necessary to fulfill our service demands. This capability enhances resource utilization, ensures business continuity, and lowers overall total cost of ownership (TCO), letting the application owner focus on business needs.
- Improved performance. Integrating Amazon ElastiCache (Redis OSS) with Amazon ECS on AWS Fargate to cache frequently accessed data significantly improves search response times and lowers load on backend services.
- Centralized configuration management. Decoupling configuration parameters like database connection, strings, and environment variables from application code by integrating AWS Systems Manager Parameter Store, also provides consistency across tasks.
Results and metrics
ITS designed this architecture, tested, and implemented it in their production environment. ITS benchmarked this solution against their monolith application under varying factors for four months and noticed a significant improvement in air travel search speeds and overall performance. Here are the results:
Single User | Non-cloud airlist page round trip (RT) | Cloud airlist page RT | ||
---|---|---|---|---|
Leg 1 | Leg 2 | Leg 1 | Leg 2 | |
Test 1 | 29 secs | 17 secs | 11 secs | 2 secs |
Test 2 | 24 secs | 11 secs | 11.8 secs | 1 sec |
Test 3 | 24 secs | 12 secs | 14 secs | 1 sec |
Table 1. Monolithic versus modernized architecture response times
Searching round trip (RT) flights in the old system resulted in an average runtime of 27 seconds for the first leg, and 12 seconds for the return leg. With the new system, the average time is 12 seconds for the first leg and 1.3 seconds for the return leg. This is a combined improvement of 72%
Note that this time includes the trip time for our calls to reach an external vendor and receive inventory back. This usually ranges from 6 to 17 seconds, depending on the third-party system performance. Leg 2 performance for our new system is significantly faster (between 1-2 seconds). This is because search results are served directly from the Amazon ElastiCache (Redis OSS) in-memory datastore, rather than querying backend databases. This decreases load on the database, enabling it to handle more complex and resource-intensive operations efficiently.
Table 2 shows the results of endurance tests:
Endurance Test | Cloud airlist page RT | |
---|---|---|
Leg 1 | Leg 2 | |
50 Users in 10 minutes | 14.01 secs | 4.48 secs |
100 Users in 15 minutes | 14.47 secs | 13.31 secs |
Table 2. Endurance test
Table 3 shows the results of spike tests:
Spike Test | Cloud airlist page RT | |
---|---|---|
Leg 1 | Leg 2 | |
10 Users | 12.34 secs | 9.41 secs |
20 Users | 11.97 secs | 10.55 secs |
30 Users | 15 secs | 7.75 secs |
Table 3. Spike test
Conclusion
In this blog post, we explored how Internet Travel Solutions, LLC (ITS) is using Amazon ECS on AWS Fargate, Amazon ElastiCache (Redis OSS), and other services to containerize microservices, reduce costs, and increase application performance. This results in a vastly improved search results speed. ITS overcame many technical complexities and design considerations to modernize its air travel search engine.
To learn more about refactoring monolith application into microservices, visit Decomposing monoliths into microservices. If you are interested in learning more about Amazon ECS on AWS Fargate, visit Getting started with AWS Fargate.