Travel Servicing Architecture

Booking sonrası change, cancel, refund, exchange, ancillary ve schedule-change işlemlerini canonical servicing architecture ile modelleyin.

Editoryal bilgi
Advertisement

Travel booking tamamlandığında lifecycle bitmez. Asıl production karmaşıklığı çoğu zaman post-booking servicing aşamasında başlar: change, cancel, refund, exchange, ancillary update ve involuntary schedule change.

Reference architecture

Travel servicing architectureTravel servicing architecture

Mermaid source (.mmd)

Servicing intent

Servicing request doğrudan provider API çağrısı olmamalıdır. Önce internal intent oluşturun:

  • booking ID,
  • servicing operation,
  • requested changes,
  • current booking version,
  • user/agent authorization,
  • quote/rules snapshot,
  • idempotency key,
  • correlation ID.

Capability check

Her provider aynı operasyonu desteklemez. Capability map en az şunları ayırmalıdır:

  • voluntary change,
  • involuntary change,
  • cancellation,
  • partial cancellation,
  • refund,
  • partial refund,
  • exchange/reissue,
  • ancillary add/remove,
  • passenger/name correction.

Unsupported capability otomatik workaround ile gizlenmemelidir.

Quote before mutation

Change/cancel/refund işlemi önce quote/rules aşamasından geçmelidir. Kullanıcıya:

  • fare difference,
  • cancellation penalty,
  • refundable amount,
  • tax/fee impact,
  • new itinerary/product terms gösterilmeden mutation başlatılmamalıdır.

State separation

Booking, payment ve document/ticket state ayrı tutulur.

text
BookingState
PaymentState
Ticket/DocumentState
ServicingAttemptState

Bir cancellation booking state'i değiştirebilir ama refund daha sonra tamamlanabilir.

UNKNOWN servicing

Servicing request timeout olursa eski booking state'ine dönmek güvenli değildir. Provider mutation'ı uygulamış olabilir. UNKNOWN state ve reconciliation gerekir.

Concurrent servicing

Aynı booking üzerinde iki change/cancel request paralel çalışmamalıdır. Booking version veya servicing lock kullanın.

Provider event reconciliation

Schedule change, cancellation veya ticket update provider tarafından async gelebilir. Webhook/event:

  • dedup edilmeli,
  • ordering kontrol edilmeli,
  • local user-initiated servicing attempt ile correlate edilmelidir.

Failure modes

  • quote ile execution arasında rule değişmesi,
  • change başarılı ama payment adjustment başarısız,
  • cancellation başarılı ama refund incomplete,
  • ticket reissue başarısız,
  • stale booking version ile mutation,
  • duplicate servicing retry,
  • provider event ile local attempt race condition.

Observability

  • servicing success rate,
  • quote-to-execution mismatch,
  • change/cancel latency,
  • UNKNOWN servicing count,
  • refund age,
  • reissue failure rate,
  • reconciliation resolution rate,
  • manual intervention rate.

Production checklist

  • capability map,
  • quote-before-mutate,
  • booking version guard,
  • operation-scoped idempotency,
  • UNKNOWN state,
  • payment/document state separation,
  • reconciliation,
  • audit trail,
  • manual ops fallback.
Teknik danışmanlık

Mimarinizi birlikte review edelim.

Travel distribution ve metasearch mimarinizi ölçeklenebilirlik, hata senaryoları ve operasyon açısından değerlendirebiliriz.

Projenizi konuşalım →

İlgili içerikler