---
title: "Direct Connect Architecture: Supplier'dan OTA ve Metasearch'e"
description: "Hotel, CRS veya airline sisteminin OTA/metasearch'e doğrudan bağlandığı topology'yi ownership, mapping, retry ve reconciliation ile tasarlayın."
slug: "direct-connect-architecture"
translationKey: "guide-direct-connect-architecture"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["travel-distribution","architecture","canonical-model"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
technicalVerifiedAt: "2026-09-26"
codeExampleStatus: "illustrative"
sources:
  - title: "Booking.com Connectivity APIs"
    url: "https://developers.booking.com/connectivity/docs"
  - title: "Google Hotel Prices"
    url: "https://developers.google.com/hotels/hotel-prices"
---
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ış

```text
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.