Travel Platform Architecture
Built for a distributed, event-driven world.
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 service surface and the ontology it executes are documented in the API and ontology reference; the thesis behind it — one canonical model, every interface a projection of it — is stated at the platform thesis.
UnityTrip is designed to work with your existing GDS, ERP, and expense relationships, while owning the fleet and joint-venture asset layer no content supplier reaches.
Bolting distribution onto a monolith does not hold; the data model fights back. Benjamin Kappel, Co-founder and Principal Architect, took distributed systems as the premise, and every decision in the stack flows from that.
That premise is also the continuity story. The system is designed so that no single person has to hold it in their head: every environment rebuilds from source through infrastructure as code, every decision replays from the event-sourced record, and the service surface and ontology are documented in the open. Resilience is a dial: a live replica in a second region, the application in both regions, or writes in both, each a setting with a price; The second shift sets out the choice. A public status page for the website is published at platformstatus.unitytrip.com. The same property works for the operator: the platform is institutional memory when teams churn.
The production architecture
The Stack
Azure Container Apps over Cosmos DB, infrastructure as code
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 and Agentic Operation
React the moment something happens — not on a batch cycle
Because every action is an event, the Cosmos DB change feed lets quota-approved bookings, re-accommodation and automations off the booking path react as it happens.
Why Event-Sourcing
Absorb 10 to 1,000 times demand surges without falling over
Corporate travel is bursty; a schedule change or crew rotation generates a flood of activity in minutes. UnityTrip is designed to absorb 10 to 1,000 times surges because work is queued and streamed, not held in a single contended database. The largest surge observed in production so far ran at twenty times baseline.
Multi-Tenant
Onboarding is configuration, not a migration project
Each client is an isolated tenant, provisioned automatically through infrastructure as code.
Integration
Bring your own travel content — your relationships stay yours
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.
Security
Zero-trust by design, not added later
No implicit trust between components; every request is authenticated and authorised. Role-based access control across all flows, and access is minimal by design — each component and operator sees only what its role requires. See our full Security and Trust page →
Constrained Networks
Built to work on bad internet
Remote operations run on constrained links — offshore platforms, site camps, satellite backhaul, congested regional networks. The booking flow is deliberately light: lean payloads, few round trips, state held server-side — verified under browser network throttling, and usable on connections where heavier applications struggle. This is a distinct promise from offline-market support (bookings made by phone and email), which the platform also governs.
Common questions
Is UnityTrip multi-tenant, and how long does onboarding take?
Each client is an isolated tenant, provisioned automatically through infrastructure as code. Onboarding is configuration, not a migration project — measured in weeks, not months.
Can a general-purpose AI assistant replace a platform like UnityTrip?
Not in any straightforward way. What would have to be replaced is a coordination layer, not an application, and a coordination layer is noticed only when it is removed. The operation is complicated: many event sources and many roles, with bookings, changes, approvals and claims arriving asynchronously over days and weeks under rules no two operations share. UnityTrip mirrors that environment rather than simplifying it, which is why it cannot be specified in a requirements document and why a general model has nothing to copy. What holds it together is two gates applied across every actor the operation touches, a booking number for travel and a claim number for spend, and a deterministic engine that decides every booking the same way with the rule attached. UnityTrip uses frontier AI where it is strong, at build and configuration time; an AI assistant is a client of that layer, not a replacement for it.