Package Holiday Distribution Architecture

Paket tatil ürünü, yalnızca hotel + flight toplamı değildir. Türkiye mevzuatındaki paket tur tanımları ulaşım, konaklama ve diğer turizm hizmetlerinden en az ikisinin birlikte sunulabildiği birleşik bir ürünü tarif eder. Teknik tarafta bunun sonucu şudur: package offer, component offer'lardan türetilir ama kendi identity, price, cancellation ve booking state'ine sahip olmalıdır.

Problem ve neden önemli?

Hotel inventory doğru, flight inventory doğru ve transfer mevcut olabilir; buna rağmen package bookable olmayabilir. Component availability ile package availability aynı şey değildir. Tour operator contract, allotment, departure rule, minimum participant, insurance, margin ve package-specific cancellation condition ayrı state üretir.

Canonical data model

Bir package offer için minimum entity seti:

PackageOffer
 ├─ packageId
 ├─ departureDate / returnDate
 ├─ travelers
 ├─ destination
 ├─ components[]
 │   ├─ HotelComponent
 │   ├─ FlightComponent
 │   ├─ TransferComponent
 │   └─ OtherServiceComponent
 ├─ totalPrice
 ├─ currency
 ├─ priceComponents[]
 ├─ cancellationPolicy
 ├─ source / tourOperator
 ├─ observedAt
 └─ bookingReference / sourceOfferRef

Component'lerin kendi supplier ID'leri korunmalıdır. Package-level identity, hotel ID veya flight itinerary ID ile eşitlenmemelidir.

Bundle identity

Aynı hotel + aynı flight, farklı meal plan, transfer, baggage, room type veya cancellation kuralıyla farklı package olabilir. Fingerprint üretirken yalnız supplier name ve total price kullanmak duplicate/merge hatası yaratır.

Pricing

Package total price; hotel, flight ve transfer fiyatlarının basit toplamı olmak zorunda değildir. Contracted net rate, markup, discount, child pricing, occupancy, transfer inclusion ve campaign package-level sonucu değiştirebilir.

Bu nedenle component gross/net values, package total, mandatory taxes/fees, discount ve commission/margin ayrı tutulmalıdır.

Availability ve freshness

Her component farklı hızda değişebilir. Hotel allotment dolabilir, flight fare family kapanabilir veya transfer cutoff geçebilir. Package freshness tek timestamp ile yönetilmemeli; package observedAt yanında component freshness de tutulmalıdır.

Booking lifecycle

SEARCH
 → PACKAGE_SELECTED
 → REPRICE
 → COMPONENT_HOLD / VALIDATION
 → PAYMENT_AUTHORIZED
 → COMPONENT_CONFIRMATIONS
 → PACKAGE_CONFIRMED

Bir component confirm olurken diğeri fail ederse PARTIAL_CONFIRMATION veya UNKNOWN gibi explicit state gerekir. Blind retry duplicate flight/hotel reservation yaratabilir.

Cancellation / amendment

Package cancellation, component cancellation kurallarının toplamı değildir. Tour operator package-level policy uygulayabilir. Bir flight non-refundable iken hotel partially refundable olabilir; traveler'a package-level consequence gösterilmelidir.

Failure mode'lar

• traveler count mismatch,
• room occupancy ile flight passenger type mismatch,
• component currency normalization hatası,
• stale package price,
• transfer cutoff,
• partial booking,
• duplicate component reservation,
• cancellation propagation hatası,
• supplier booking reference kaybı.

Observability

Package search → reprice success, component validation failure, stale-price delta, partial-confirmation rate, duplicate-booking rate, cancellation reconciliation drift, component vs package margin ve abandonment izlenmelidir.

Trade-off'lar

Dynamic packaging daha fazla combination ve personalization sağlar fakat search-space, pricing ve booking orchestration maliyetini büyütür. Pre-built packages daha kontrollü inventory sunar ama flexibility ve real-time supply coverage daha düşüktür.

Production checklist

• Package ve component identity ayrılmış mı?
• Her component source/provider reference taşıyor mu?
• Package total ile component prices ayrı mı?
• Reprice booking öncesi çalışıyor mu?
• Partial-confirmation state var mı?
• Idempotency component bazında korunuyor mu?
• Cancellation package + component seviyesinde reconcile ediliyor mu?
• Freshness component bazında gözleniyor mu?