Travel Event Reconciliation Architecture

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ış

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