Booking Timeout ve Duplicate Booking Playbook

Booking create çağrısında timeout olduğunda en tehlikeli hata, sonucu bilinmeyen işlemi otomatik olarak tekrar göndermektir. Supplier rezervasyonu oluşturmuş olabilir; client sadece response'u alamamış olabilir.

Trigger / belirti

Create-order/create-booking request'i timeout olur, network connection kapanır veya 5xx alınır ve local sistemde booking reference oluşmaz.

Amaç

İşlemin gerçekten oluşup oluşmadığını kanıtlamadan ikinci create çağrısı göndermemek; customer ve supplier tarafında duplicate booking riskini minimize etmek.

Gerekli girdiler

• internal booking attempt ID,
• idempotency key varsa değeri,
• supplier request ID,
• traveler/guest identity,
• itinerary/property + dates,
• amount/currency,
• request timestamp,
• payment authorization state.

Adımlar

1. Attempt'i UNKNOWN state'e alın; FAILED olarak işaretlemeyin.
2. Aynı payload ile otomatik immediate retry yapmayın.
3. Supplier idempotency destekliyorsa aynı key ile documented retry akışını kullanın.
4. Booking lookup/retrieve endpoint'i varsa request ID, traveler ve itinerary ile arayın.
5. Payment tarafında authorization/capture state'i kontrol edin.
6. Supplier booking bulunduysa local record'u reconcile edin.
7. Booking bulunamaz ve provider'ın safe retry şartları sağlanıyorsa kontrollü retry yapın.
8. Sonuç hâlâ belirsizse manual review/escalation kuyruğuna alın.

Duplicate detection

Aynı traveler + product + stay/flight + close timestamp kombinasyonu tek başına kesin duplicate değildir, ama investigation key olabilir. Supplier booking reference, idempotency key ve payment transaction ID daha güçlü kanıttır.

Stop conditions

Attempt CONFIRMED, definitively NOT_CREATED veya MANUAL_REVIEW state'lerinden birine geçmelidir. UNKNOWN state sonsuza kadar kalmamalıdır.

Escalation

Payment captured fakat booking bulunamıyorsa veya iki supplier reference oluşmuşsa finans/ops ve supplier ekibini aynı incident'e dahil edin.

Metrikler

Unknown booking age, duplicate booking rate, idempotency hit rate, reconciliation latency ve manual-review volume.

Önleme

Her booking create işlemine stable attempt ID verin. Provider destekliyorsa idempotency key kullanın. Request/response loglarını PII minimization kurallarıyla audit edilebilir tutun.