Reactive application covering big US aerospace.

Industry

Technology

Akka Akka-http Elasticsearch Kafka Postgres Scala Titan (with Cassandra)

Introduction

The application was best suited for reactiveness, and the entire Lightbend reactive technology stack helped achieve it. Since the application is based on microservices, the design is highly extendable and scalable. Moreover, the application would never face downtime if one part of it gets dysfunctional.

About Freebird

Freebird provides a mobile flight rebooking platform that enables travelers to skip the line and instantly book a new ticket on any airline in the event of a flight cancellation, four-hour delay, or missed connection. This platform provides travelers with instant notifications in the event of flight disruption and offers the ability to rebook through their mobile devices. The project ‘thePlatform’ is intended to make the B2B processes easier. It allows partners to interact with the platform. The flow for the platform goes something like this; a partner buys a freebird by doing pricing and purchasing; if the flight somehow gets disrupted, the traveler gets an SMS as well as an email with different rebooking options. The traveler then can select one option, and freebird books a new ticket for them.

The challenge

Though the basic flow for the application is very simple, the challenge comes when the application needs to cover the whole US aerospace to check for disruption. Since a single source could not be trusted, multiple sources are used to track the status of the flights. The status needs to be fetched and ingested into the database frequently so that the rebooking options can be sent instantly to the travelers. Every time the statuses are being fetched from the sources, many changes in their statuses take place, hence the need to process huge amounts of data frequently. This is only one challenge for the platform, and it needs to handle the availability of the flights as well and that too with partner’s preferences

Another challenge is to find out alternate flights for the trip if it gets disrupted. The available flights again need to be fetched from different sources. Every trip has different scenarios with different preferences; all of them must be created successfully before hitting the alternate flight sources. Once the alternate flights are generated, send them as options to the traveler, as well as make enough information for the customer care service so that they can handle the situations crisply.

Though API seems the simplest of all the challenges, however, it needs to process a lot of operations to generate enough information so that disruption monitoring can be done easily. It needed to handle the requirement of searching not only the client-generated data but also the flight information which gets ingested in the backend.

Our solution

NashTech started working to build the application using the DDD approach. Bounded contexts were identified and the application was made with the Microservices Architecture. Except for the API for pricing and purchasing, everything else was asynchronous. The architecture was designed choreographically, and we used kafka as the message broker among the services. It provided a unified, high-throughput, low-latency platform for real-time handling data feeds where its storage layer is essentially a “massively scalable pub/sub message queue architected as a distributed transaction log. Inside each service, we used Scala’s functional programming, futures, and, wherever needed Akka extensively as everything had to be non-blocking and asynchronous. The data ingestion process was massive; therefore, to handle the back pressure, Kafka was used in many places.

As we ingest a massive amount of data into the databases, searching needed to be handled carefully, and hence Elastic Search was used. It holds the part of the data based on what the search could have been done and returns the index point through which the updated data could be fetched from the database.

NashTech’s way of development using Scrum and XP was used to build the project in sprints. The benefit of being agile was found a lot during the project’s development lifetime. High focus was on TDD by considering the pyramidal test cases strategy where we have the least number of e2e test cases, more integration test cases than e2e, and mostly unit test cases. GitFlow was used as the branching strategy so that there was no challenge in code management.

The outcome

The technology stack and architecture met the SLAs which were required for the platform. The application was best suited for reactiveness, and the entire Lightbend reactive technology stack helped achieve it. Since the application is based on microservices, the design is highly extendable and scalable. Moreover, the application would never face downtime if one part of it gets dysfunctional.