---
title: "Booking Timeout ve Duplicate Booking Playbook"
description: "Booking create timeout sonrası unknown state ve duplicate reservation riskini idempotency, lookup ve reconciliation adımlarıyla yönetin."
slug: "booking-timeout-duplicate-prevention-playbook"
translationKey: "playbook-booking-timeout-duplicate"
locale: "tr"
type: "playbook"
category: "operations"
tags: ["booking","timeout","idempotency","duplicate","reconciliation"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

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.