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 a 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, 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.

Though the basic flow for the application is very simple, challenge comes when the application needs to cover the whole US aerospace to check for disruption. Since, 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 in the database frequently, so that the rebooking options could be sent instantly to the travelers. Every time the statuses are being fetched from the sources a lot of changes in their statuses take place, hence need to process huge amount of data frequently. This is only one challenge for the platform, it needs to handle the availability of the flights as well and that too with partner's preferences

Another challenge is to find out the 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 need to 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 simplest of all the challenges however, it needs to process a lot of operations for generating enough information so that disruption monitoring could be done easily. It needed to handle the requirement of searching, on not only the client generated data but also the flight information which gets ingested in the backend.

Knoldus started working to build the application using the DDD approach. Bounded contexts were identified and the application was made with the Microservices Architecture. With the exception of the api for pricing and purchasing, everything else was asynchronous. The architecture was designed in a choreographic way and we used kafka as the message broker among the services. It provided a unified, high-throughput, low-latency platform for handling real-time 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 process of data ingestion was massive therefore in order 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 handle carefully, and hence ElasticSearch was used. It holds the part of the data on the basis of what the search could have been done and returns the index point through which the updated data could be fetched from the database.

Knolway (Knoldus 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 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 is no challenge in code management.

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 achieving 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.