AWS Database Blog

Enhance the reliability of airlines’ mission-critical baggage handling using Amazon DynamoDB

In the world of air travel, baggage handling isn’t just about keeping track of baggage, but a seamless orchestration of different processes to improve the passenger baggage experience. A key component to make this happen is a strong database management strategy. This makes sure that every step of handling baggage—acceptance, loading, unloading, rerouting, and handling any issues like lost baggage—is done with great accuracy and efficiency.

Traditional methods, which are often reliant on manual processes and outdated systems, pose challenges in quickly adapting to the dynamic nature of airline business processes. Consequently, the airline industry actively seeks fresh and innovative solutions.

In this post, we discuss how AWS Partner IBM Consulting developed an initiative to modernize a traditional baggage database architecture using Amazon DynamoDB and other Amazon Web Services (AWS) managed services, addressing the evolving needs of the airline industry.

Traditional database management strategies for baggage handling

Traditional database management strategies in baggage handling often use monolithic relational database systems. These face multiple challenges, including outdated technologies, delays in speed to market, high operational costs, and limited disaster recovery strategies. Collectively, these issues impede the efficiency, agility, and cost-effectiveness of the system, underscoring the need for a modernized and adaptive approach to baggage management. The following diagram illustrates a traditional architecture.

Traditional baggage handling systems integrate data feeds from flights, passenger journeys, and partner airlines. These systems connect with downstream and upstream systems such as aircraft weight and balance, operational reports, reference data management, and devices such as handheld scanners, belt loaders, sortation belts, and kiosks.

The cost of mishandled baggage in the airline industry was around USD 2.4 billion in 2019 according to Airport Industry Review, including expenses for baggage delivery, passenger compensation, and lost productivity of airline staff. This also leads to revenue loss due to dissatisfied customers, delayed flights, and missed connections, which incur additional costs. Problems such as departure scanning delays, loading irregularities, inability to track and load transfer bags during application downtime, and manual flight closing lead to mishandling, misplaced, or damaged baggage. These inefficiencies lead to poor customer experiences and frequent flight delays. Additionally, system unavailability and limited turnaround time (time interval between an aircraft’s arrival at an airport and its departure on the next flight) can result in physical offloading without actual scanning, leading to forgotten cargo, extra fuel burn, misplaced commodities, and frequent weight data record (WDR) arrival audits. The inability to track and reroute bags during arrivals and to notify customers of baggage status exacerbates these challenges, resulting in increases in baggage delay claims and customer dissatisfaction.

Airlines face significant monetary impacts and legal penalties due to system availability issues, which affect both downstream and upstream systems. This necessitates adopting a strategic architectural objective to achieve 99.999% availability by using a multi-Region active-active disaster recovery strategy with near-zero Recovery Point Objective (RPO) and Recovery Time Objective (RTO) while optimizing costs and improving scalability to handle traffic bursts during irregular operations (IROPS).

Need for modernization

The following are the primary challenges that exist in the current on-premises baggage database system:

  • Single points of failure – The baggage application uses a centralized database, which is a classic example of single-point-of-failure (SPOF). Failure of the centralized database with an active-passive disaster recovery (DR) strategy and longer recovery time can collapse the entire baggage ecosystem, causing significant delays, mishandling, and customer dissatisfaction.
  • Scalability challenges – The centralized database, limits scalability and performance of individual application components, which increases downtime, longer wait times, and more baggage mishandling.
  • Limited flexibility – Tightly coupled application components and a rigid relational schema design make adapting to evolving business needs, regulations, or technological advancements exceptionally challenging, hindering innovation and agility.
  • Complexity and maintenance challenges – Large, intricate, and tightly integrated systems are difficult to maintain and enhance, leading to prolonged release cycles and increased maintenance overhead.
  • Innovation impediment – The monolithic database restricts adopting new technologies, best practices, or alternative solutions, hindering efforts to enhance operational efficiency and customer experience. The current database’s inability to handle increased device volume poses a significant barrier to innovation and modernization efforts.

Solution overview

The challenges posed by the current architecture of baggage handling databases necessitate a comprehensive solution. The following diagram introduces a modernization strategy that effectively addresses these challenges by decomposing a monolithic database into subcapabilities.

The strategy of decomposing the monolithic database into sub-capabilities aligns with domain-driven design principles, which emphasize breaking down complex domains like baggage management into more manageable business capabilities. This approach enhances performance and scalability and promotes flexibility and adaptability in response to evolving business needs. The solution divides the baggage management process into distinct functions or business capabilities, such as baggage acceptance, loading, offloading, mishandling and claims, rerouting, notifications, and tracking. Each capability is designed to have exclusive ownership of its data, with attributes tailored to meet the specific requirements of each function.

Key benefits:

  • Enabling separate read and write capacities – By decomposing the monolithic database, the solution enables separate read and write capacities across separated capabilities, each having its own table. This approach enhances write performance in various processes, including managing incoming feeds from upstream systems and improving the efficiency of time-sensitive messages. Furthermore, it facilitates the integration of many Internet of Things (IoT) devices, including Radio Frequency Identification (RFID) scanners.
  • Enabling separate disaster recovery strategy for each capability based on business needs – Certain baggage management capabilities, such as baggage acceptance, baggage loading, tracking, and offloading are deemed mission-critical, and others may be classified as not mission-critical.

The proposed solution uses Amazon DynamoDB global tables to effectively address the low latency, high scalability, and disaster recovery requirements needed for multi-Regional active-active solutions with 99.999% availability, offering near-zero RPO, near-zero RTO, point-in-time recovery (PITR).

DynamoDB is serverless and can automatically scale to thousands of transactions per second to support sudden bursts during irregular operations while optimizing costs compared to its relational counterpart. By leveraging warm throughput, you can ensure your DynamoDB tables handle these bursts efficiently. For further information, refer to: Understanding DynamoDB warm throughput.

Additionally, baggage data is considered airline confidential and hence requires encryption at rest and in transit. DynamoDB offers both client-side and server-side encryption. For further information, refer to Client-side and server-side encryption. For scenarios in which the data needs to be concealed from web or mobile applications, additional data obfuscation can be applied at API layer to protect sensitive information (e.g. PNR, passenger name).

The following diagram depicts the baggage operational database architecture using DynamoDB. Each capability has a corresponding microservice and separate Amazon DynamoDB global tables. This makes sure baggage check-in systems such as kiosks and reservations use the baggage acceptance table and microservices, while baggage loading systems such as handheld scanners and belt loaders use the baggage loading table and microservices. Similarly, downstream systems only interface with the specific capability based on data ownership, bringing clarity to the information flow.

Database design

The solution uses a DynamoDB single-table design for each capability. For example, baggage acceptable information will be maintained in a single DynamoDB table while the baggage loading capability will have its own table, mainly because each capability will have different information and different access patterns. In each single-table design, DynamoDB allows for a unified data model, where different types of information related to baggage management can be stored within a single table. This eliminates the need for complex relational structures and simplifies data retrieval and manipulation. It’s important to have a separate database table for each capability for isolation and separation of responsibilities according to domain design principles. For more information, refer to Single-table vs. multi-table design in Amazon DynamoDB.

The following figure illustrates a partitioning strategy for baggage loading capability using hypothetical values, with ATL representing a station, KT as an operating airline code, and 1234 and 3333 as flight numbers.

An entity represents a well-defined schema for a DynamoDB item. For the baggage domain, the solution may use database entities such as ACCEPTED_BAG, CONTAINER, BAGS_LOADED, and BAGS_OFFLOADED in a DynamoDB table. Because we will be managing multiple database entities in a single table, prefixing the sort key with the ENTITY_NAME will help improve the query performance of the specific entity in the application.

The following figure depicts a hypothetical representation of flights, where the respective container is positioned on the aircraft, and bags are loaded within the container using a single-table design. ContainerID_1 is positioned on flight XY1234 departing from station ABC and is represented using partition key ABC#XY#1234 and sort key CONTAINER#2023-01-01#CONTAINERID_1. A bag with bag tag ID BAG_ID1 is placed inside the same container and is represented using partition key ABC#XY#1234 and sort key BAG#2024-01-1#BAG_ID1.

When the solution is deployed in production and has been running for a while, you can use Amazon CloudWatch Contributor Insights to find the most accessed and throttled items in your table. CloudWatch Contributor Insights is a diagnostic tool that provides a summarized view of your DynamoDB table’s traffic trends and helps you identify the most frequently accessed partition keys. With this tool, you can continually monitor the graphs for your table’s item access patterns. Choose a high cardinality key to distribute the read and write operations as evenly as possible and avoid poor performance. For more information, refer to Designing partition keys to distribute your workload in DynamoDB and Choosing the Right DynamoDB Partition Key.

Managing aggregations within DynamoDB

Baggage handling systems often display or publish running counts of bags across various capabilities such as local, transfer, rerouted, loaded, unloaded, offloaded.

In a traditional relational database, aggregation combines rows into one based on a criterion, often using aggregate functions for calculations. DynamoDB lacks built-in aggregation, but you can use precomputed aggregates instead. In baggage management, aggregated views optimize queries, improve performance, and reduce latency by accessing precomputed data.

As depicted in the following figure, SUMMARY is a newly introduced entity serving as a precomputed aggregate that retains the summary of loaded counts across different categories of bags. The solution aims to increment and update SUMMARY as bags are scanned and new entries of the SCAN entity are generated.

The solution uses Amazon DynamoDB Streams to process updates on the DynamoDB table. An AWS Lambda function reacts to changes in the specific entity and updates the SUMMARY entity in the aggregated view. For more information, refer to Implement resource counters with Amazon DynamoDB. In case duplication of records is not a major concern, one could use Amazon Kinesis Data Streams for DynamoDB. For further information, please refer to Streaming options for change data capture and Choose the right change data capture strategy for your Amazon DynamoDB applications.

Depending on the scenario, the solution may opt to update the aggregates within the same transaction, whereas in alternative approaches, it may choose to use a background process.

Managing data consistency with multi-Region architecture

To support mission-critical applications, the architecture needs to use a multi-Region approach. When using DynamoDB global tables, business use cases must be evaluated for data consistency requirements. DynamoDB supports both eventual and strongly consistent reads for global tables. For more information, refer to Amazon DynamoDB global tables previews multi-Region strong consistency and Consistency and Conflict Resolution.

Data migration

A data migration strategy is required to support coexistence during the phased rollout of a baggage handling system across various stations. The solution proposes AWS Database Migration Service (AWS DMS) for continual migration of data from on-premises relational databases to DynamoDB. It’s a fully managed service that facilitates the swift and secure migration of databases to AWS. It supports homogeneous (moving data between two similar database systems) and heterogeneous (moving data between two different types of database systems) migrations, enabling seamless data transfer across various database engines and AWS services.

Moving from an on-premises relational database to a NoSQL database such as DynamoDB typically requires data transformation. This transformation process might encompass format adjustments, type conversions, or consolidating multiple tables to create single or multiple entities in DynamoDB. As depicted in the following figure, you can achieve this conversion by using a staging DynamoDB instance and a Lambda function to update the target table.

Conclusion

In summary, the challenges stemming from the monolithic architecture of existing baggage database systems are substantial and wide-ranging. These challenges encompass scalability limitations, inflexibility, the risk of single points of failure, and complexity in maintenance, all of which highlight the pressing need for modernization. Moreover, this antiquated structure inhibits innovation, impeding the integration of new technologies and thereby hampering efforts to bolster operational efficiency and enhance the customer experience.

This is where DynamoDB emerges as a transformative solution. DynamoDB offers numerous benefits, including elastic scalability, with the ability to handle vast amounts of data and fluctuating workloads effortlessly. Its flexible architecture enables rapid adaptation to changing requirements, providing agility in response to dynamic industry trends. Additionally, the built-in fault tolerance and redundancy mechanisms of DynamoDB mitigate the risk of single points of failure, providing uninterrupted service even in the face of unforeseen challenges.

Check out more AWS Partners or contact an AWS Representative to learn how we can help accelerate your business.

To learn more about AWS and the travel sector, refer to the following:

IBM Consulting is an AWS Premier Tier Services Partner that helps customers who use AWS to harness the power of innovation and drive their business transformation. They are recognized as a Global Systems Integrator (GSI) for over 22 competencies, including Travel and Hospitality Consulting. For additional information, please contact an IBM Representative.

About the Authors

Neeraj Kaushik is an Open Group Certified Distinguished Architect at IBM with two decades of experience in client-facing delivery roles spanning various industries, including travel and transportation, banking, retail, education, healthcare, and anti-human trafficking. As a trusted advisor, he works directly with the client executive and architects on business strategy to define a technology roadmap. As a hands-on Chief Architect, AWS Professional Certified Architect and Natural Language Processing Expert, he has led multiple complex cloud modernization programs and AI initiatives.

Ravindran Yelchur is a Solutions Architect at IBM with three decades of IT experience and is currently working in IBM Hybrid Cloud Services. He is a certified AWS Solutions Architect and primarily focuses on cloud modernization across various industries in a customer-facing delivery role.

Akshayakumar Patil is a Database Architect at IBM with a decade of experience spanning several industries, including supply chain, banking, and travel and transportation, in a client-facing delivery role leading large modernization across several hyperscalers, including the AWS Cloud.

Jay Pandya is a Senior Partner Solutions Architect in the Global Systems Integrator (GSI) team at Amazon Web Services. He has over 30 years of IT experience and provides guidance to AWS GSI partners to build, design, and architect agile, scalable, highly available, and secure solutions on AWS. Outside the office, Jay enjoys spending time with his family and traveling, is an aviation enthusiast, and is an avid sports and Formula 1 fan.

Amit Chowdhury is a Senior Partner Solutions Architect in the Global System Integrator (GSI) team at Amazon Web Services. He helps AWS GSI partners migrate customer workloads to AWS, and provides guidance to build, design, and architect scalable, highly available, and secure solutions on AWS by applying AWS recommended best practices. He enjoys spending time with his family, outdoor adventures, and traveling.