The following diagram describes the architecture for creating and updating reservations triggerd by events from the Travel Updates Receiver and User Agent Quanta, as well as managing trips
Stateful component that consumes curated events from downstream Event Filterer component and Reservation API component.
- Utilizes a specialized DB that handles efficiently write-intensive workloads
- Emit events to a dedicated topic/queue containing updated reservation records
Stateful component that consumes reservation record events
- Utilizes a specialized DB that is optimized for read-intensive workloads
- Groups reservations to Trips to be presented in the UIs/dashboard
Service that exposes an API interface for communicating with the internal systems.
- Acts as a communication layer between the reservation orchestrator and the other Quanta
- Contains logic for performing CRUD operations on reservations and trips
- Maintain a cache (In-Memory Database) for improved performance and latency
Stateless module that curates reservation record events to produce a notification to the end user
Stateless module that handles the delivery of notification through multiple notification channels (email, sms, mobile-app)
Hybrid: Microservices - Event Driven Architecture
- We also considered a service oriented architecture due to the low performance requirements originating from our assumptions. That would considerably reduce complexity of the quantum, with a single component and a single database handling reservations/trips.
- In such a scenario the notification sender would be moved to the user agent (in any case an external notification API for mobile devices could be used).