- Members
- Mission The Road Warrior
- Approach
- Architecture
- Deployment
- Use cases
- Video Presentation
- References and credits
- Alvaro Salvador LinkedIn
- Anand Bajpai LinkedIn
- Constantine Korobov LinkedIn
- Mirco Paccusse LinkedIn
- Sergiy Shelekh LinkedIn
A new startup wants to build the next generation global online trip management dashboard to allow travelers to see all of their existing reservations organized by trip either online (web) or through their mobile device. Build a sustainable architecture for same.
We follow actor/action model to begin with. We identify the actors and actions they need to perform. We, then, create components which will enable actors to perform specific actions. Next, we find interactions among actors. This provides us high level view of actors components required in the system, their relation to stakeholders and their (inter)dependency.
We create use case diagrams to visualize the functional requirements to assists us making design choices and understanding the system on more granular level.
Now we understand the desired system behavior better so we qualify the requirements to identify architecture characteristics. These characteristics help us identify the most suitable architecture style for the solution.
We use C4 model technique to design the architecture, starting with most abstract view of the system and going further in details in each step.
We use ADR approach to make a informed decision for all important architecture decisions.
First iteration
Second iteration
This exercise is primarily focused on defining the architectural style and structure of the system. While we acknowledge the critical importance of security, access management, high availability, encryption, GDPR and backup in the overall system design, these aspects are not within the scope of this proposal. Our intention is to first establish the architectural foundation, and subsequently, these implicit aspects will be addressed in a separate, dedicated effort.
- Space based architecture style
- Microservices vs Event driven architecture style
- Dedicated storage for analytics
- Storing agency contact details for help
- One Analytics Generator for yearly user report and other analytics
- Analytics generator and Analytics exporter
- Efficiency oriented algorithm for booking tracker
- Deploying system in cloud or on premise
The C4 model is an "abstraction-first" approach to diagramming software architecture, based upon abstractions that reflect how software architects and developers think about and build software.
Below is presented in detail the different interactions identified within the component architecture.
User Access Stack
Our users access the RoadWarrior via the CDN where we can cache static resources for fast worldwide delivery based on proximity. This then feeds into the API Gateway which is the main artery for all user interactions. Frontend components offer the user access via Web site and support Mobile Apps in popular platforms such Android and iPhone.
Booking Core
Next is the booking core, which consists of three components: the Booking Storage, the Booking Engine – the orchestrator for the lifecycle of tracked user bookings and CRUD operations on the storage-, the Booking Tracker –an ephemeral component that tracks the status of all bookings via integrations with third parties.
Booking Tracker requires a high degree of elasticity to support a rapid increase in bookings for the 15-mil user-base. We envision this to be implemented by single-use lambda functions corresponding to each booking tracked, that need to be launched on a certain schedule.
Composed of three components
- Booking engine: acting as orchestrator in context with the lifecycle of the bookings tracked for the end users
- Booking Trackers. Ephemeral component which is responsible to track booking status and report if any relevant change
- Booking storage. Main storage of the stack
- Booking engine interacts also directly with some third parties in limited scenarios to gather local meaningful data regarding the bookings tracked
- Northbound wise Booking Engine offers to perform CRUD operations on the booking storage, consumed mainly by Frontend stack and Data Exporter from the Data Analytics stack
Data Analytics
The next block is Data Analytics, which is one of the most crucial for monetization and survivability of the RoadWarrior. The purpose of this block is to gather booking events and populate the analytics storage, where they are then processed into metrics, that can be shared with third-parties.
Event Stack
Event stack is at the heart of our event-driven architecture. It has an event broker, which integrates in a bus fashion different consumers and providers of events. Its design allows to incorporate more providers (eg: more booking companies) as well as comsumers (eg: new platform components) without requiring uplifting any development into the existing components so far integrated.
Mail Stack
Supports integration with email providers in a proactive and passive manner.
- Mail poller proactively query relevant providers for the end users
- Mail listener receives emails from the end user inbox in case the user has setup its mailbox to forward or copy emails to be scanned.
- Mail filterer receives events from both components and enforces which emails shall trigger a booking-relevant event, based on the user configuration.
Third Parties Stack
This is the third party integration stack which provides a common interface API. This allows different components from the platform to request data from the third parties on demand It is composed of connectors, which can be added and scaled. Every connector maybe responsible to interface with a specific third party southbound wise, while offering a common API northbound which can be consumed by any component internally in the platform.
Interaction matrix
| Id | From Component | To Component | Interaction type | Communication Domain | Observations |
|---|---|---|---|---|---|
| INT-1 | End Users | CDN | HTTP | PUBLIC | Cached on CDN |
| INT-2 | CDN | API Gateway | HTTP | PUBLIC | Refresh content |
| INT-3 | API Gateway | Front End | HTTP | PLATFORM INTERNAL | |
| INT-4 | Booking Engine | Social Media Connector | REST | PLATFORM INTERNAL | |
| INT-5 | API Gateway | Booking Engine | HTTP / Streaming | PLATFORM INTERNAL | |
| INT-6 | API Gateway | Notifier | HTTP / REST | PLATFORM INTERNAL | |
| INT-7 | Event Broker | Notifier | Streaming | PLATFORM INTERNAL | |
| INT-8 | Mail Poller | Email Services | HTTP / IMAP / POP3 | PUBLIC | Active polling |
| INT-9 | Email Services | Mail Listener SMTP | PUBLIC | Passive reception | |
| INT-10 | Mail Listener | Mail Filterer | Streaming | STACK INTERNAL | Postprocess and filter emails which shall trigger an event |
| INT-11 | Mail Poller | Mail Filterer | Streaming | STACK INTERNAL | Postprocess and filter emails which shall trigger an event |
| INT-12 | Mail Filterer | Event Broker | Streaming | PLATFORM INTERNAL | Generate events based on mail filtering logic |
| INT-13 | Event Broker | Booking Engine | Event push | PLATFORM INTERNAL | |
| INT-14 | Booking Engine | Event Broker | Event pull | PLATFORM INTERNAL | |
| INT-15 | Booking Engine | Booking storage | HTTP / REST / GraphQL | STACK INTERNAL | CRUD operations |
| INT-16 | Booking Engine | Partners Connector | REST | PLATFORM INTERNAL | Request context data for a booking |
| INT-17 | Booking Engine | Booking Trackers | REST | STACK INTERNAL | Create tracker tasks |
| INT-18 | Data Exporter | Booking Engine | REST / GraphQL | PLATFORM INTERNAL | Read / Import data for analytics |
| INT-19 | Data Exporter | Analytics Storage | Streaming | STACK INTERNAL | Store data for analytics |
| INT-20 | Event Broker | Data Exporter | Streaming | PLATFORM INTERNAL | Booking events relevant for analytics |
| INT-21 | Analytics Generator | Analytics Storage | Streaming | STACK INTERNAL | Import and generation of reports |
| INT-22 | Analytics Exporter | Analytics Storage | Streaming | STACK INTERNAL | Read analytics and reports |
| INT-23 | Analytics Exporter | Analytics Users | Streaming | PUBLIC | Expose analytics and reports |
| INT-24 | Analytics Users | Analytics Exporter | HTTP / REST / GraphQL | PUBLIC | Consume analytics and reports |
| INT-25 | Agencies Connectors | Travel Agencies | HTTP / REST | PUBLIC | Retrieve booking status |
| INT-26 | GDS Connectors GDS | HTTP / REST | PUBLIC | Retrieve booking status | |
| INT-27 | Booking Trackers | Agencies Connectors | REST | PLATFORM INTERNAL | Request booking status update |
| INT-28 | Booking Trackers | GDS Connectors | REST | PLATFORM INTERNAL | Request booking status update |
| INT-29 | Booking Trackers | Event Broker | Streaming | PLATFORM INTERNAL | Booking event |
| INT-30 | Social Media Connector | Social Media | HTTP / REST | PUBLIC | Share booking info |
| INT-31 | Partners Connector | Partners | HTTP / REST | PUBLIC | Get complementary info to support location based features |
Implement Architectural Fitness Functions
- User adds booking manually
- Booking added via email scan
- User shares trip information in social media
- User shares trip information with other user(s)
- User request help to remediate a booking incident
- Agency updates booking status
- User personal yearly reports
- Data analytics and information access
- Rich user experience based on time and/or geolocation info
Video Download link : WATCH
Though it is not possible to mention every source material we were benefitted from, while working on this solution, we would lile to mention following as noteworthy