NDC Offer/Order Lifecycle: Search'ten Servicing'e
NDC Offer/Order lifecycle'ını search, offer, revalidation, order create, payment, ticketing, servicing ve reconciliation state'leriyle modelleyin.
NDC'de Offer ile Order aynı entity değildir. Offer shopping anındaki airline retail proposition'ıdır; Order ise booking sonrası transaction/servicing state'idir. İki lifecycle'ı tek DTO'ya sıkıştırmak stale price, duplicate booking ve servicing hatası üretir.
Canonical state machine
NDC Offer to Order to Ticket lifecycle
Offer identity
Offer fingerprint dedup için kullanılabilir ama provider offer/reference yerine geçmez.
Tutulması gerekenler:
- source/carrier,
- offer ID/reference,
- observedAt,
- expiry,
- itinerary,
- fare family,
- baggage,
- ancillaries,
- total/components,
- penalties.
Revalidation
Offer select edildikten sonra stale state riski büyür. Provider destekliyorsa revalidation/refresh sonucu explicit state üretmelidir.
same -> continue
price changed -> user reconfirm
expired/unavailable -> re-shopOrder create ve unknown state
Network timeout sonrası “failed” demek tehlikelidir.
create sent
-> response confirmed
-> response rejected
-> no definitive response = UNKNOWNUNKNOWN durumda retrieve/reconcile yapılmadan ikinci create gönderilmemelidir.
Ticketing != Order
Order confirmed olması ticket/document issuance tamamlandı demek değildir. Booking/order, payment ve ticket/document state ayrı saklanmalıdır.
Schedule change / servicing
Post-booking lifecycle:
- involuntary schedule change,
- voluntary change,
- exchange,
- cancel,
- refund,
- ancillary change
provider/carrier capability'lerine göre farklı olabilir.
Observability
- offer age,
- reprice-change rate,
- create unknown rate,
- order-to-ticket latency,
- schedule-change lag,
- servicing failure,
- refund reconciliation.
Anti-patterns
- itinerary == offer varsaymak,
- offer == order varsaymak,
- PNR == ticket varsaymak,
- timeout == failure varsaymak,
- source lineage'i normalization sırasında silmek.
Failure modes
- stale offer ile order create,
- order confirmed fakat ticket issuance başarısız,
- duplicate order create,
- ancillary/fare family bilgisinin normalization sırasında kaybı,
- schedule change event'inin local state'e geç yansıması,
- servicing capability'nin provider bazında yanlış varsayılması.
Production checklist
- Offer ve Order ayrı entity,
- revalidation explicit,
- UNKNOWN order state,
- ticket/document state ayrı,
- provider/carrier capability map,
- servicing/reconciliation path,
- source lineage korunması,
- end-to-end correlation IDs.
Benzer bir entegrasyon mu planlıyorsunuz?
Gereksinim, feed/API tasarımı ve production yaklaşımını birlikte değerlendirebiliriz.