Direct Connect Architecture: Supplier'dan OTA ve Metasearch'e

Direct Connect bir şirket kategorisi değil, iki sistem arasında aracı distribution hub zorunluluğu olmadan kurulan integration topology'sidir. Hotel/CRS → OTA, hotel/CRS → metasearch veya airline → seller bağlantısı doğrudan contract ile işletilebilir.

Temel akış

Source System
  → Canonical Adapter
  → Partner API
  ← Ack / Reservation / Order
  → Reconciliation

Ownership

Source of truth her field için belirlenmelidir. Property/room identity, ARI, restriction, booking ve payment state aynı sistemin sahipliğinde olmak zorunda değildir.

Mapping ve state

Partner-specific IDs canonical modele bağlanmalı; delta update, idempotency key, source timestamp ve version bilgisi korunmalıdır. HTTP 200 downstream business state'in doğru olduğunu tek başına kanıtlamaz.

Retry ve reconciliation

Timeout sonrası create/update işlemi bilinmeyen state'te olabilir. Blind retry duplicate booking veya duplicate inventory mutation üretebilir. Lookup/reconciliation path zorunludur.

Ne zaman tercih edilir?

Direct connect daha az hop ve daha fazla kontrol sağlayabilir; fakat certification, partner-specific maintenance ve 7/24 operasyon yükünü de doğrudan ekibe taşır.

Failure modes

• provider timeout sonrası duplicate booking retry,
• provider-specific ID/state bilgisinin canonical modelde kaybolması,
• local booking confirmed iken provider state'in farklılaşması,
• mapping drift nedeniyle yanlış property/rate eşleşmesi,
• webhook/polling evidence'ının sırasız uygulanması.

Observability

Provider success/error rate, p95/p99 latency, UNKNOWN booking count, reconciliation age, mapping failure rate ve duplicate-prevention hit'leri izlenmelidir.

Production checklist

• provider adapter boundary,
• canonical request/response model,
• explicit timeout budget,
• idempotency,
• UNKNOWN + reconciliation path,
• source/provider reference preservation,
• mapping/version strategy,
• provider-level metrics ve trace.