Travel Feed Nedir? XML, JSON ve Metasearch Veri Akışları

Feed, bir sistemden diğerine düzenli ve machine-readable veri aktarmak için kullanılan structured data akışıdır.

Travel entegrasyonlarında XML, JSON, CSV veya platform-specific formatlar kullanılabilir. Feed kelimesi tek bir dosya anlamına gelmez; data contract, update stratejisi ve processing lifecycle'ı da kapsar.

Feed hangi problem için uygundur?

Feed özellikle bulk veya tekrarlı senkronizasyonda kullanışlıdır. Feed, sık değişmeyen veya toplu taşınması verimli olan property, ürün, içerik ve katalog verilerini düzenli biçimde aktarmak için uygundur. Gerçek zamanlı fiyat ve availability için çoğu zaman API veya push/query modeli gerekir.

Örnekler:

• hotel master data,
• static content,
• room metadata,
• rate-plan metadata,
• landing page configuration.

Her kullanıcı aramasında değişen live availability için feed tek başına yeterli olmayabilir.

Hotel List feed

Property identity verisini taşır.

Tipik alanlar:

• partner hotel ID,
• name,
• address,
• country,
• coordinates,
• phone,
• website.

Bu feed mapping kalitesinin temelidir.

Room ve rate metadata

Room/rate display için şu bilgiler taşınabilir:

• room name,
• occupancy,
• bed information,
• meal,
• cancellation policy,
• rate-plan name.

Pricing verisinin user-facing anlamı metadata ile birlikte oluşur.

Pricing ve availability

Bazı sistemler rate/inventory değişikliklerini push veya feed tarzı akışlarla iletir.

Kritik boyutlar:

• effective date,
• stay date,
• inventory,
• restrictions,
• currency,
• tax/fee scope.

Landing page feed

Metasearch offer click sonrası doğru booking page'e gitmelidir.

Landing configuration URL template, language, currency, device ve campaign parametrelerini içerebilir.

Feed ve API farkı

Feed genellikle producer-driven veya batch oriented'tır.

API çoğunlukla request/response ve on-demand erişim sağlar.

Pratikte bir entegrasyon ikisini birlikte kullanabilir:

• static hotel data → feed,
• live availability → API,
• conversion → event/API.

Full feed vs incremental feed

Full

Tüm current state gönderilir.

Avantajı reconciliation'ın kolay olmasıdır. Dezavantajı büyük hacimdir.

Incremental

Sadece değişen kayıtlar gönderilir.

Avantajı verimliliktir. Dezavantajı change tracking ve recovery karmaşıklığıdır.

İyi sistem periyodik full snapshot ile incremental update'i birlikte kullanabilir.

Idempotency

Aynı feed iki kez işlendiğinde veri bozulmamalıdır.

Stable IDs ve deterministic upsert mantığı önemlidir.

Versioning

Schema değişiklikleri production entegrasyonlarını kırabilir.

Feed versioning için:

• explicit version,
• backward-compatible additions,
• deprecation window,
• contract tests

kullanın.

Validation

Göndermeden önce required fields, enum values, date formats, currency, duplicate IDs, invalid coordinates, malformed syntax ve referential integrity kontrol edilmelidir.

Observability

Takip edin:

• generated records,
• accepted records,
• rejected records,
• processing duration,
• last successful sync,
• schema errors,
• source-data freshness.

Feed “dosya üretildi” diye başarılı sayılmamalıdır; downstream processing görünür olmalıdır.

Özet

İyi travel feed tasarımı:

stable identity + explicit schema + update strategy + validation + observability

gerektirir.

Feed'i dosya transferi değil data contract olarak düşünün

Production feed entegrasyonunda CSV/XML/JSON formatı yalnız taşıma biçimidir. Asıl contract; identity, schema version, mandatory field, update semantics ve deletion davranışıdır.

Örneğin bir hotel catalog feed'inde şu sorular cevaplanmalıdır:

• provider property ID stable mı?
• record full snapshot mı delta mı?
• eksik field "değişmedi" mi "silindi" mi?
• property kapanırsa nasıl tombstone edilir?
• image/amenity listesi replace mi append mi?
• schema version nasıl evolve olur?

Ingestion pipeline nasıl görünmeli?

Receive
  -> checksum / size validation
  -> schema validation
  -> record parsing
  -> canonical mapping
  -> business validation
  -> quarantine invalid records
  -> stage
  -> diff
  -> publish
  -> reconciliation report

Invalid tek record yüzünden tüm feed'i reddetmek ile hatalı record'u sessizce atlamak arasında kontrollü quarantine katmanı kurulmalıdır.

Failure mode'lar

• aynı dosyanın iki kez işlenmesi,
• partial upload'ın complete sanılması,
• schema değişikliğinin parser'ı bozması,
• deletion semantics'in kaybolması,
• provider ID reuse,
• encoding/locale problemi,
• duplicate property,
• stale feed'in yeni feed'den sonra işlenmesi.

Idempotency için feed run ID, checksum ve source timestamp tutulmalıdır.

KPI ve operasyon

• records received/accepted/rejected,
• duplicate rate,
• mapping success,
• quarantine count,
• feed age,
• ingest duration,
• schema error distribution,
• deleted/reactivated entities,
• last successful publication.

Bir feed entegrasyonu "dosya geldi" ile değil, canonical data'nın güvenilir şekilde publish edilmesiyle başarılıdır.