AWS Solution to Provide Airport Lounge Customers up to Date Flight and Gate Information via the Lounge App
For frequent travellers, airport lounges provide a haven from the chaos of the airport. An airport lounge app that provides real-time flight and gate information can be a useful tool for any frequent traveller as it removes the need to get up from where they are sat and check the board.
An airline approached us to deliver an in-app departures notification system as part of a larger application modernisation project for airport lounges. To give their First and Business Class travellers up-to-date flight and gate information to improve their pre-flight experience, the airline used two existing data sources across their digital portfolio, neither of which were the perfect fit for the in-app departures notification system.
One of the services was a HTTP endpoint meaning we couldn’t get data in real-time and the other supplied us with real time data, but it is not customer facing and is updated too often with data that the user does not need to know about.
In this blog post, I will explain how we leveraged the existing data sources to deliver as close to a real-time solution as possible, without creating unnecessary load on downstream services.
The blog will explore how I created a serverless solution using AWS and the Serverless Framework to build an API that integrates with the lounge app so that users can get flight and gate information in real-time.
Designing The Solution
The two existing services available that store the information we needed both had advantages and disadvantages.
Service A was a good choice because it provides a WebSocket endpoint which can be subscribed to, but the data is often manually changed by a real person behind a desk. The data is not customer facing and often becomes inaccurate.
Service B provides a HTTP endpoint which means to check for updates, a request has to be sent each time. Also, this service already receives millions of requests per day, so it was necessary to be careful with how many calls are made because I didn’t want to be the one to overload it! That being said, the data is already customer facing, meaning it is reliable and only contains data the customer is allowed to see.
I went for service B. Due to the fact that the data is already customer facing, less money is spent on compute time for the Lambda functions because data doesn’t need to be manipulated to ensure we only have the data we need for this application. Read on to find out how I used AWS Step Functions to keep the number of calls to this service to a minimum.
I chose to use the following AWS resources to try to minimise costs and meet business requirements:
- AWS AppSync to provide a GraphQL API that can be accessed via the frontend application, update in real-time and be able to scale to millions of connections
- AWS DynamoDB to store flight and gate information and act as a datastore for the AppSync API
- DynamoDB Streams, which were used to call a Lambda function. This Lambda kicks off an AWS Step Functions workflow
- An AWS Step Functions workflow which handles the periodic fetching of up to date flight information from an external API, as well as calling a lambda function, which contains some business logic to decide whether or not to push an update to the frontend
Implementing the Solution
To build the solution, I decided to use the Serverless Framework, which is an open-source framework that simplifies the process of building serverless applications.
I used AWS Step Functions to fetch data periodically. The idea is that we have a Step Functions workflow per flight, but only if there is someone in the lounge who has requested information for that specific flight. There are hundreds of flights taking off per day, but it will not fetch data for a specific flight if nobody has requested that data.
In the first step of the AWS Step Functions workflow a Lambda function fetches the data for the given flight from the external API. When it has fetched the data, it gets compared with the data we already have in DynamoDB. If the data is not the same, it publishes a mutation on the AppSync API that updates the DynamoDB and pushes the update to the frontend in real-time.
The second step of the AWS Step Functions workflow is a “choice” step. If the flight has taken off, the workflow ends and the record is removed from the database after 30 minutes have passed. If the flight has not taken off, it will go to a “sleep” step, where it will sleep for X number of minutes, depending on how soon the flight is due to take off. I made the sleep step dynamic, dramatically reducing the number of calls to the datastore as well as our AWS costs, all while still giving a dynamic user experience.
When a user requests information for a specific flight, it will check to see if information for this flight is already in the database. If it is, it will subscribe to this data. However, if it is not already in the database, it will add the PK and SK for this item into the database and create the subscription. Then, DynamoDB streams will use a Lambda function to kick off the AWS Step Functions workflow for the given flight number. The good thing about this is that there will only ever be one instance of Step Functions running for a given flight, even if there are 20 customers in the lounge requesting information for this flight.
The DynamoDB table was implemented with single table design principles in mind, meaning we have one table for everything. This means a flight is stored in the same table as a gate, see below for an example of the PK’s and SK’s on this table.
AWS AppSync was chosen for our API so that we could create GraphQL subscriptions between the frontend and backend. For a real-time application like this, it allows us to give users information as they are waiting for their departure.
Conclusion
By using the Serverless Framework and AWS services, we were able to create a reliable and scalable solution for an airport lounge app that provides real-time flight and gate information. The solution acts as a cache, utilising AWS Step Functions to update flight and gate information periodically, depending on how soon the a flight is due to take off. AWS AppSync and DynamoDB streams were used to provide real-time updates to the frontend, and AWS Step Functions ensured we only made the necessary calls to the external API, reducing the overall load on the system. This solution could now be consumed by other applications throughout the business to make fetching flight and gate information easy and painless.
About Leighton
Leighton is a software development business that builds high performing teams and develops successful software applications for its customers. We’re on a mission to help organisations and their customers thrive in today’s fast paced world. For as long as we can remember (and we’ve been around for 30 years) organisations have struggled to deliver digital change. That’s where we come in. We help organisations thrive by bringing people and technology together.
