Technical architecture · 28 October 2026 · Neerej Sasikumar
Order Amendment Concurrency: Preventing Stale NDC Changes and Lost Updates
Practitioner focus: simultaneous seller changes, stale snapshots, Order version conflicts and recoverable servicing.
Two people can legitimately change the same airline Order at almost the same moment. A traveller selects a new flight in self-service while a consultant cancels a seat. An operational schedule change may alter the itinerary before either request completes. The issue is not simply whether two API calls return success: it is whether the resulting Order, payment and service obligations remain coherent.
This article focuses on concurrent amendments to an existing Order, rather than API schema versioning or duplicate OrderCreate. Which Order snapshot did each actor read, which change won, and how should the losing request recover? The scenarios below are independent practitioner patterns, not claims about any airline or supplier.
1. What the IATA standard guidance actually describes
The IATA Enhanced and Simplified Distribution 21.3 Implementation Guide, “Order Versioning,” pages 94–95, describes an external integer version starting at one. The airline decides which significant changes advance it and may maintain more granular internal versions. A group of changes can advance the external version once. This describes Order versioning, not a universal database transaction design.
The guide says a seller can supply the version it believes current in OrderChangeRQ. Its recommended practice is to send that version; when a supplied version does not match the current one, the airline should return an error. It also discusses versions in OrderViewRS, change notifications and Order History. An Order version alone does not make overlapping writes safe without an atomic decision at the owning system.
IATA’s NDC implementation-issues guidance identifies missing Order History as an operational blocker: sellers may miss changes made directly with the airline or lose notifications. It notes that version numbering helps detect missing updates. That supports recovery design, but it does not prescribe the locking or retry algorithms proposed here.
2. Three different versions, three different jobs
| Version | What it represents | Owner |
|---|---|---|
| Message schema release | NDC message structures and optional features | Applicable standards release and agreement |
| External Order version | Business snapshot a seller believes current | Order-owning airline |
| Internal mutation sequence | Storage transactions or events accepted in order | OMS implementation |
A seller may use the latest message schema yet amend an old business snapshot. An OMS may record several internal events without incrementing the externally exposed version for every event. The integration contract should document that distinction. Do not silently substitute a database row counter for the external version, because the two can advance differently.
3. A lost-update scenario
At 09:00 a seller retrieves Order ORD-4821, version 7, containing a flight and paid seat. At 09:01 an airline schedule change creates version 8. At 09:02 the seller submits an itinerary amendment based on version 7. Blind acceptance could overwrite the updated itinerary, break the seat association or apply a price based on obsolete conditions.
A version-aware process detects the mismatch and returns a conflict rather than an unexamined write. The seller retrieves the latest Order, reviews the changes and seeks fresh customer confirmation where necessary. A previously selected replacement Offer or payment authorization must not automatically be treated as valid for the revised state.
A second race occurs when two sellers both read version 8 and submit changes before either sees a response. Version comparison and accepted mutation must be atomic within the authoritative Order boundary. A check at an API gateway followed by a delayed write is insufficient: both requests might pass the check. Atomicity is a practitioner engineering recommendation, not an additional IATA message requirement.
4. Compare-and-commit as a business boundary
Authenticate the actor, authorize the requested operation and resolve the authoritative Order owner. Read the current snapshot, compare the supplied base version where supported, validate passenger and product associations, and reserve the right to commit through an atomic transaction or serialized command processor. Persist the new Order and a durable change record before acknowledging success.
On mismatch, return a stable conflict category and correlation identifier. The exact response envelope and error codes must follow the implemented NDC release and bilateral agreement; there is no universal error code invented here. If an expected-version field is unsupported, document weaker guarantees and require retrieve-and-revalidate before consequential changes.
Concurrency checks are distinct from business validation. A matching version does not prove a flight remains available or a payment is approved. A stale change to an unrelated contact field might be safe to merge, but only if dependency analysis proves that. Automatic merge is a policy choice, not a default.
5. An illustrative internal amendment contract
This JSON is not an NDC schema. It sketches what an OMS adapter might track while mapping actual OrderChange and OrderView messages to the selected release.
{
"orderId": "ORD-4821",
"expectedExternalVersion": 8,
"commandId": "change-73b2",
"actor": {"role": "seller", "sellerRef": "agency-42"},
"change": {"type": "replace-flight", "itemId": "ITEM-2"},
"offerReference": "RESHOP-17",
"correlationId": "trace-20261028-91"
}The command identifier deduplicates one logical amendment; the expected version guards against stale state. They solve different problems. A retry with the same identifier and identical payload should recover the previous outcome. Reusing the identifier for different payloads should fail. Order versioning alone cannot prevent duplicate payment or fulfilment side effects after a timeout.
6. Recovery after a version conflict
First, stop blind retries. Retrieve the current Order, then compare passengers, Order Items, services, price, currency, payment and delivery obligations with the earlier snapshot. Decide whether the original customer instruction remains meaningful. If it does, reshop or reprice as necessary and submit a new amendment against the current version.
For a schedule change, do not infer customer approval of a replacement flight. The IATA AIDM Seller Follow Up Action model describes possible actions and an action time limit following an involuntary change. Available options depend on the Order and implementation. Preserve the distinction between airline-initiated change and seller choice.
If retrieval fails, park the command in a recoverable pending state, explain the uncertainty to the customer and raise an operational exception. For irreversible actions, require explicit current-state verification or human resolution when the outcome of an earlier commit cannot be established.
7. Out-of-order notifications and missed history
Version-aware writes do not automatically synchronize downstream readers. A seller may receive version 11 before version 10 because notifications traverse different queues. Store the highest contiguous applied version, detect gaps and request Order History or a current snapshot when supported. Never overwrite a newer authoritative snapshot with an older event merely because it arrived last.
IATA 21.3 links OrderChangeNotifRQ, OrderHistoryRQ/RS and versioned ChangeOperationGroup records. A practical consumer can maintain an inbox keyed by Order and event identity, suppress duplicates and replay missing changes. Where Order History is unavailable, agree a snapshot-reconciliation fallback with the partner.
8. Payment and fulfilment can race too
Suppose a seller authorizes a fare difference for a replacement itinerary, then loses the amendment race. Authorization is not evidence that the Order changed. Track payment attempts and Order mutations separately; reconcile ambiguous outcomes and release unused authorizations under provider rules. The ledger should reflect the accepted business outcome, not callback arrival order.
A cancelled seat might already be in delivery or refund processing. Do not simply overwrite its status. Coordinate with fulfilment and legacy ticket or EMD components where relevant, recording the accepted action and compensation. For adjacent checkout clocks, read Payment Deadline vs Offer Validity.
9. A race-focused acceptance test matrix
| Test | Expected evidence |
|---|---|
| Two amendments from version 8 | One conflicting mutation commits; other receives recoverable conflict |
| Duplicate command after timeout | Prior result recovered without duplicate side effects |
| Version 11 notification before 10 | Gap detected; history or snapshot recovery initiated |
| Schedule change during reshop | Offer and passenger associations revalidated |
| Payment authorized, amendment rejected | Payment and Order states reconciled |
Use independent seller sessions, not sequential calls from one UI. Capture before-and-after Order snapshots, versions, timestamps, correlations and downstream effects. Inject delayed notifications, duplicated callbacks and lost acknowledgements. Success means the final customer obligations are consistent, not merely that one request failed.
10. Operational measures and release gates
Track conflict rate by operation and channel, self-service recovery percentage, time to refresh an Order, missing-version gaps, duplicate-command suppression and unresolved payment-to-Order mismatches. Separate voluntary change, disruption, ancillary and interline cases; a global error rate can conceal material servicing risk.
Before automating recovery, define conflict ownership, history availability, command retention, customer reconfirmation rules and reconciliation of stuck commands. These are suggested release gates, not IATA certification criteria. Test the policy whenever the OMS, seller adapter or payment workflow changes.
11. Standards versus practitioner recommendations
Published guidance: IATA describes external Order versions, version-aware OrderChange, notifications and history. Its 21.3 guide recommends supplying the known version and returning an error on mismatch. Practitioner recommendations: atomic compare-and-commit, deduplication, gap detection, compensation, customer conflict handling and telemetry are independent implementation controls. Verify actual element paths, optional features and error handling against the deployed release and partner agreement.
Original references and related reading
- IATA Enhanced and Simplified Distribution 21.3 Implementation Guide, “Order Versioning” pp. 94–95 and “Order History” pp. 95 onward.
- IATA NDC TMC implementation issues, Accelerator #7, Order History and missed updates.
- IATA AIDM 25.1: Seller Follow Up Action, model definition.
- IATA ONE Order programme, unified Order principles.
Related MAR analysis: Airline API idempotency and schema versioning, Seller servicing and Interline servicing handoffs. This guide addresses concurrent mutations to one Order rather than repeating those broader subjects.
Independent technical education. Illustrative identifiers, workflows and controls are not official NDC payloads or representations of an airline implementation. Confirm the standards release, bilateral agreement, payment rules and local obligations before deployment.