Architectural Katas - Fall 2023

This repository is our solution to the Fall 2023 O'Reilly Architectural Katas Challenge.

The goal of the challenge is to enable Road Warrior, a startup aspiring to be a single source of truth for all things related to the trips of its users, to meet its objective.

About Us

Our team consists of Apostolos Mantes, George Lourakis, George Panagiotakis, Konstantinos Polydorou and Spyros Economopoulos. We are members of Neurocom SA, a greek company focusing mainly on the telecommunication sector, located in Greece.

Back to Contents

Challenge Overview

The Vision

Be the single source of truth for all things trip related.

The Scope

At this stage focus on

flights
hotels
car rentals

Keep in mind the vision and consider how the platform will embrace trains, buses, attractions etc. etc.

Back to Contents

Domain Design

Actors and Use Cases

The identified actors and use cases appear in the following diagram

Which led to the identification of the initial building blocks of the system

Back to Contents

Quanta Identification

We utilized the quantum concept during our analysis to identify parts of the system that serve different needs and demonstrate different characteristics.

This is the final list along with each quantum responsibilities

User Agent
- Interact with the user (display dashboard, receive commands etc.)
- Capture analytics metrics
- Store and publish user profiles
- Share content to social media via related APIs
- Redirect user to preferred agent website (retrieved from user profile) when asking for help
Travel Updates Receiver
- Connect with travel agent and travel systems
- Receive notifications and filter the ones of interest
- Translate notifications to the system internal format and push them to the reservation orchestrator
Email Receiver
- Connect to our email server and poll for forwarded reservations
- Connect to user mailboxes and filter out travel related emails (reservation + updates)
- Translate message information to the system internal format and push them to reservation orchestrator
Reservation Orchestrator
- Receive user requests from the user agent and return relevant information
- Receive user commands from the user quantum and update trips/reservations accordingly
- Receive messages from travel notifications and email receivers and update trip accordingly
Analytics Capture
- Collect analytics data from user agent, email receiver and travel update receiver quanta and store them for analysis
- Anonymize data for use with analytics consumers
- Prepare yearly reports and push them to end users through the user agent

Back to Contents

Architecture

System-Wide Architecture

Drivers

Key Metrics

2 Million Weekly Active Users
15 Million Total Users
800 ms web response time
1.4 sec mobile app contentful paint
5 minutes end to end update limit
99.99% ("four nines") availability

Assumptions

We assume that most, e.g. 80%, of the users will mostly interact with the app within a four - hour time frame in working days corresponding to 1.6M users accessing the site in 5 * 4 * 3600 = 72K sec, leading to an expected number of 25 requests / second.

We do not expect a sudden burst of requests, maybe an increase in holiday periods but certainly not something we will make us have to respond immediately.

Assuming an average of 5 reservations per active user (to accommodate attractions or events) and an average trip duration of two weeks we expect 2 million * 5 = 10 million reservations per two weeks = 5 million per week (~250 million reservations per year).

We expect on average 5 updates per reservation => 25 million relevant update events per week (of course the updates we will have to process will be much higher. Suppose we have captured 5% of the market we expect 20 times this number in total, leading to 500 million update events per week), i.e. ~1000 reqs per second.

Email parsing, if we consider the 'share your mailbox approach' is much more challenging. Suppose 30% of our users have opted in for this option and that the average user receives 100 emails per day, we need to filter 30% * 5M * 100 = 150M emails per day, i.e. ~4000 reqs per second.

Additional Drivers

The system must interoperate with as many as travel agent API's as possible
We plan to expand to international markets

Back to Contents

System-Wide Architecture Characteristics

Given the above we have identified the following top three architecture characteristics:

Availability: Since the application must be available to ensure the best customer experience
Interoperability: Since we need to interoperate with a lot of travel agents at both national and international level
Scalability: Since we both plan to expand and anticipate periods with higher traffic

Additional applicable characteristics that we considered were:

Performance (especially with regard to external information sources): We decided to address it in the quantum level
Deployability: To allow us to quickly onboard new travel agents and reservation types. This will be aided by allowing each quantum to be deployed separately (and possibly in parallel).
Fault Tolerance: To allow the system to operate in case of e.g. network issues with external agents / travel systems and/or email providers. We consider that we can address this issue with the CRUD operation provided to the end user as well as the option to parse email updates on top of confirmation emails.
Configurability: Since this will be an international application with different time zones, currencies, confirmation email languages etc. etc.
Data Consistency: To avoid false notifications to alarm the user or miss important information. Again, we decided to address this issue in the corresponding quanta.
Security: we did not identify a specific security requirement (apart from GDPR which we addressed in the analytics quantum) and email sharing which we expect to be standardized.

Selected Architecture

Based on the characteristics identified, and using the provided template, we came up with the following top matching architectures:

We decided to select a hybrid microservices event-driven architecture because it both scores well in most of our characteristics and fits well with asynchronous processing which we think is central to our application.

Back to Contents

System-wide Architectural Diagram

The system-wide architecture is depicted in the following diagram

Quanta and Related Architectures

We then focused on each quantum and discussed the characteristics that it should demonstrate. Here is what we came up with: