📄️ 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.