Architecture
Most corporate travel platforms are monoliths with integrations bolted on. UnityTrip was built the other way around: a distributed, event-sourced system where integration is the architecture.
The Stack
Runs on Azure Container Apps over Cosmos DB, all infrastructure defined as code through BICEP. Container apps scale on demand, Cosmos DB handles globally distributed event-driven data, and IaC means every environment is reproducible and a new tenant is provisioned in minutes. The system is event-sourced — every booking, change, and approval is an event — giving a complete audit trail and real-time reactions rather than batch.
Change Feed & Agentic Operation
Because every action is an event, the Cosmos DB change feed lets downstream processes — automated approvals, re-accommodation, agent-driven workflows — react the moment something happens, rather than on a batch cycle. The architecture is built for agentic operation, not retrofitted for it.
Why Event-Sourcing
Corporate travel is bursty; a schedule change or crew rotation generates a flood of activity in minutes. UnityTrip is designed to absorb 10–1000x surges because work is queued and streamed, not held in a single contended database.
Multi-Tenant
Each client is an isolated tenant; provisioning is automated through IaC; onboarding is configuration, not a migration project.
Integration
Holds your travel rules and customisations in one portal; commodity verticals plug in per client — travel content (NDC/GDS/aggregator/corporate provider you already run), payment gateways, guesthouse and accommodation management, land transport and fleet scheduling, identity and ERP systems. You bring the relationships you have; UnityTrip orchestrates them.
Security
No implicit trust between components; every request is authenticated and authorised. Role-based access control across all flows. All service credentials managed centrally in Azure and rotated rapidly, containing a suspected compromise in minutes.