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 sit above your existing GDS, ERP, and expense relationships — consuming them as content while owning the fleet and JV asset layer no content supplier reaches.

Introducing distributed systems into travel technology is harder than it looks. Many have attempted it and found that bolting distribution onto a monolith foundation doesn't hold — the data model fights back, the operational complexity compounds, and the promises made to customers don't survive contact with production.

UnityTrip succeeded because Benjamin Kappel, Co-founder and Principal Architect, approached it the other way: distributed systems as the premise, not the retrofit. Every decision in the stack flows from that starting point.

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. Live availability is published at platformstatus.unitytrip.com. The same property works for the operator: the platform is institutional memory when teams churn.

The Stack

Azure Container Apps over Cosmos DB, infrastructure as code

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

React the moment something happens — not on a batch cycle

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

Absorb 10–1000x 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–1000x surges because work is queued and streamed, not held in a single contended database.

Multi-Tenant

Onboarding is configuration, not a migration project

Each client is an isolated tenant; provisioning is automated through IaC; onboarding is configuration, not a migration project.

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. You bring the relationships you have; UnityTrip orchestrates them.

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 & 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.