---
title: "Travel Event Reconciliation Architecture"
description: "Booking, payment, cancellation ve supplier event'lerini kaynaklar arasında uzlaştıran deterministic reconciliation mimarisini tasarlayın."
slug: "travel-event-reconciliation-architecture"
translationKey: "architecture-travel-event-reconciliation"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["reconciliation","booking","payment","event","travel"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Travel sistemlerinde booking, payment, webhook ve provider report aynı gerçeği farklı zamanlarda ve farklı kimliklerle anlatabilir. Reconciliation katmanının görevi **hangi state'in authoritative olduğunu kanıtlamak ve tutarsızlıkları izlenebilir biçimde çözmektir**.

## Production senaryosu

Booking create timeout oluyor. Provider daha sonra CONFIRMED webhook'u gönderiyor. Payment tarafında capture var; internal DB hâlâ UNKNOWN. Gece gelen supplier report'unda aynı booking reference tekrar görünüyor.

## Mimari akış

```text
API Response / Webhook / Payment / Supplier Report
 -> Normalize Event
 -> Correlation Keys
 -> Deduplication
 -> Event Ordering
 -> State Comparison
 -> Reconciliation Rule
 -> Corrective Action
 -> Audit Record
```

## Correlation keys

- internal booking ID
- booking attempt ID
- provider reference
- idempotency key
- payment transaction ID
- traveler/product/date composite key

Composite key yalnız fallback olmalı; stable provider/internal identifiers daha güçlüdür.

## Reconciliation rule

Her source için authority tanımlayın. Örneğin booking existence için provider booking reference, payment state için PSP transaction state, commercial settlement için matured supplier report daha güçlü olabilir.

## Trade-off

Real-time reconciliation düşük latency sağlar ama karmaşıktır. Batch reconciliation daha basittir ama inconsistency daha uzun yaşar.

İkisi birlikte kullanılabilir: critical mismatch için near-real-time, finansal doğrulama için batch.

## Failure modes

- duplicate event,
- missing webhook,
- provider report gecikmesi,
- out-of-order cancellation,
- payment captured / booking missing,
- booking confirmed / payment failed,
- aynı provider reference'ın iki internal record'a bağlanması.

## Idempotency ve replay

Reconciliation job tekrar çalıştırılabilir olmalı. Aynı evidence set'i aynı sonucu üretmelidir.

## Observability

- unreconciled count,
- reconciliation latency,
- auto-fix rate,
- manual-review rate,
- booking/payment divergence,
- duplicate reference count.

## Alternatifler

Düşük hacimli sistemde günlük SQL reconciliation yeterli olabilir. Çok provider ve ödeme akışı olan sistemde explicit event/reconciliation service daha sürdürülebilirdir.

## Production checklist

- source authority matrix
- stable correlation keys
- idempotent rules
- replay support
- audit trail
- manual review queue
- financial vs operational reconciliation separation