📄️ Architecture Overview
Nexa is engineered for operational panic — the microscopic windows during a Tier-1 hub closure when dozens of agents compete for limited hotel inventory while tens of thousands of stranded passengers hit the platform from their phones. The architecture is built from four patterns that compose: event-driven workflows, read-side isolation for passenger traffic, distributed coordination for inventory and operator concurrency, and anti-corruption adapters for every external partner.
📄️ Case Lifecycle
A case represents one disrupted flight; a sub-case represents one PNR (Passenger Name Record) within that case — typically one passenger or a family group. The case orchestrator is the central state machine of the platform; everything else exists to advance a sub-case from PENDING to RESOLVED.
📄️ Data Model
Every persisted and on-the-wire identifier in Nexa is a URN. URNs are structural — the partner and live status are part of the identifier itself, not side fields. That single rule eliminates a category of bugs that plagues platforms with opaque numeric IDs: you never need an if/else chain to figure out which adapter to call, and you never lose track of whether r-8842 is the Nexa-side ID or a partner-side locator.
📄️ Rebooking Engine
During a mass disruption (such as a severe weather storm closing a hub), finding and securing alternative flights for thousands of stranded passengers is a major bottleneck. The Nexa Rebooking Engine automates the search, generation, and locking of alternative flight options, allowing operators to present viable routes to passengers and enabling passenger self-service selection.
📄️ Real-time Collaboration & Swarm Coordination
When a major flight disruption occurs, a team of airline agents (an Operator Swarm) opens the same flight manifest to begin rebooking passengers, issuing hotel vouchers, and coordinating ground transit.