---
title: "Sync vs Async Travel Booking Architecture"
description: "Travel booking akışlarında synchronous ve asynchronous orchestration modellerini latency, failure recovery, UX ve provider capability açısından karşılaştırın."
slug: "sync-vs-async-travel-booking"
translationKey: "architecture-sync-vs-async-travel-booking"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["booking","sync","async","orchestration","travel"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

Travel booking'de sync ve async yaklaşım bir framework tercihi değil, **provider response semantics ile kullanıcıya verdiğiniz booking contract arasındaki sınırdır**.

## Kısa cevap

Provider birkaç saniye içinde kesin CONFIRMED/FAILED sonucu döndürüyor ve timeout sonrası authoritative lookup sunuyorsa synchronous orchestration yeterli olabilir. Provider booking'i daha sonra kesinleştiriyor, webhook ile sonuç veriyor veya confirmation latency değişkense async state machine gerekir.

## Sync booking

```mermaid
%% title: Synchronous booking flow
%% description: Client request provider confirmation tamamlanana kadar aynı request lifecycle içinde bekler.
sequenceDiagram
  participant U as User
  participant A as Booking API
  participant P as Provider
  U->>A: Create booking
  A->>P: Provider create
  P-->>A: Confirmed / Failed
  A-->>U: Final response
```

Avantajları:
- basit UX,
- daha az state,
- daha az queue/event altyapısı.

Riskleri:
- long-running HTTP request,
- timeout ambiguity,
- retry ile duplicate booking,
- provider latency'nin client latency'ye doğrudan yansıması.

## Async booking

```mermaid
%% title: Asynchronous booking flow
%% description: Booking request kabul edilir, provider sonucu webhook/polling/reconciliation ile daha sonra kesinleşir.
sequenceDiagram
  participant U as User
  participant A as Booking API
  participant P as Provider
  participant R as Reconciler
  U->>A: Create booking
  A->>P: Provider create
  A-->>U: Pending / accepted
  P-->>A: Webhook confirmation
  R->>P: Status lookup when needed
```

Async modelde client'a terminal olmayan bir state dönebilir: `PENDING`, `PROCESSING` veya `UNKNOWN`.

## Decision matrix

| Sinyal | Sync daha uygun | Async daha uygun |
|---|---|---|
| Provider kesin response latency | düşük/stabil | değişken/yüksek |
| Final result aynı request'te | evet | hayır |
| Webhook desteği | gerekmez | değerli |
| Lookup/reconciliation | fallback | temel mekanizma |
| Client UX | immediate | pending state desteklemeli |
| Failure recovery | basit | explicit state machine |

## Hybrid model

Çoğu production sistem hybrid'dir:

1. kısa bir sync budget içinde final response beklenir,
2. budget aşılırsa booking `UNKNOWN/PENDING` olur,
3. background reconciliation devam eder,
4. webhook gelirse state güncellenir.

## Failure modes

- HTTP timeout sonrası blind retry,
- async result gelmeden FAILED gösterme,
- webhook gelmezse sonsuz pending,
- client disconnect'i booking cancel sanma,
- aynı booking için hem sync response hem webhook'u iki kez uygulama.

## Observability

- sync completion rate,
- async fallback rate,
- provider confirmation latency p50/p95/p99,
- pending/unknown age,
- reconciliation resolution time,
- duplicate event count.

## Production checklist

- explicit terminal/non-terminal states,
- request timeout ile business timeout ayrımı,
- provider-specific latency budget,
- idempotency,
- webhook dedup,
- reconciliation fallback,
- client polling/backoff contract,
- manual ops threshold.