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.
Without strict coordination, two major failure modes occur under high concurrency:
- Operator Collision: Two agents open and modify the same passenger's details simultaneously, resulting in double-allocated vouchers or lost changes.
- Inventory Overbooking: Multiple agents attempt to book the last available hotel rooms at the same millisecond, leading to overbooked hotel capacities and vendor errors.
Nexa solves these problems through two real-time mechanisms: Entity Locks and Inventory Soft-Holds, supported by a Live Session Broadcaster.
1. Entity Locks (Passenger Protection)
The Entity Lock guarantees that only one operator can edit a passenger's sub-case at any given second.
Key Functional Mechanics:
- Session-Coupled Locking: When an operator opens a passenger's profile, the Operator BFF acquires a lock in the distributed coordination store. This lock is directly bound to the operator's active session websocket connection.
- Instant Release: The moment the operator closes the passenger's tab or their session disconnects, the lock releases immediately.
- Time-To-Live (TTL) Fallback: If an operator's browser crashes or they lose internet connectivity, a defensive 90-second TTL automatically expires the lock.
- Live Lock UI: Status updates are pushed to all active operator consoles in real-time. Locked rows automatically display a 🔒 icon on all screens without manual page refreshes.
2. Inventory Soft-Holds (Hotel Protection)
If multiple operators attempt to book the last remaining rooms at a specific hotel, the Inventory Soft-Hold protocol prevents double-booking.
Instead of maintaining a shared mutable counter (such as decrementing a remaining_rooms integer, which is prone to data drift if a process crashes mid-transaction), Nexa computes available inventory dynamically:
Available Inventory = Total Capacity - (Active Holds + Confirmed Reservations)
How the Hold Protocol Works:
- Per-Attempt Key: Before making any API requests to a hotel partner, Nexa generates a unique, attempt-scoped hold key containing the case URN and the room offer URN.
- Gated Allocation Check: The coordination store runs an atomic script that checks the sum of current active holds and confirmed reservations against the hotel's configured capacity.
- Locking:
- If capacity remains, the key is written with a 90-second TTL (soft-hold), and the booking engine proceeds to call the hotel vendor's API.
- If the capacity is exhausted, the attempt is instantly rejected, and the operator sees a "Room Sold Out" alert.
- Self-Healing Resolution:
- On Success: The booking is completed, a confirmed reservation is persisted, and the hold key is removed.
- On Failure or Abandonment: The hold key is left to expire naturally. Once the 90 seconds elapse, the capacity is automatically restored without requiring any complex cleanup operations.
3. What's next
- Rebooking Engine — how flight seats are held and allocated.
- Case Lifecycle — understanding sub-case states and transitions.
- Booking Operations — how operators manage room inventory.