Travel Dağıtımında Inventory ve Availability Farkı

Inventory, bir sağlayıcının potansiyel olarak satabileceği ürünü ve stoğu tanımlar; availability ise belirli tarih, occupancy ve restriction koşullarında gerçekten neyin rezerve edilebilir olduğunu gösterir. İkisini aynı alan gibi modellemek false availability ve sold-out click üretir.

Inventory ve availability farklı soruları cevaplar

Inventory hangi ürünlerin var olduğunu ve ne kadar stok tanımlandığını, availability ise belirli bir arama bağlamında hangi ürünün gerçekten satılabilir olduğunu cevaplar. Booking.com dokümantasyonu da aynı ayrımı yapar: oda envanterde bulunabilir ama occupancy, tarih, closure veya restriction nedeniyle kullanıcıya açık olmayabilir.

Bu nedenle metasearch tarafında ikisini tek bir isAvailable alanına indirmek hatalıdır.

Availability arama context'ine bağlıdır

Check-in, check-out, yetişkin/çocuk sayısı, oda sayısı ve bazı durumlarda market veya üyelik koşulları availability sonucunu değiştirir. İki yetişkin için satılabilir olan oda dört kişi için satılamayabilir. Bir rate bir gecelik konaklamada açıkken minimum-stay kuralı nedeniyle üç gecelik başka bir aramada kapanabilir.

Availability bu yüzden hotel seviyesinden çok offer veya room-rate-date context'ine yakındır.

Restriction'lar availability'nin parçasıdır

Hotel distribution tarafında yaygın restriction örnekleri:

• open/closed durumu,
• minimum veya maximum length of stay,
• closed to arrival,
• closed to departure,
• occupancy limitleri,
• advance-purchase kuralları,
• sell limit,
• rate-plan eligibility.

Bu alanlar dikkate alınmadan bulunan fiyat teknik olarak doğru olsa bile booking'e dönüşmeyebilir.

Stale availability neden oluşur?

Yaygın problem supplier state ile cache'teki state arasındaki zaman farkıdır. Upstream'de son oda satılır fakat cache'teki teklif birkaç dakika daha görünür. Kullanıcı tıkladığında provider tarafında “no availability” görür.

Bu yalnızca cache problemi değildir; inventory, restriction, pricing ve search context senkronizasyon problemidir.

Inventory ile offer modelini ayırın

Sağlıklı bir internal model genelde şu katmanları ayırır:

1. Property — hotel identity.
2. Room type — fiziksel/ticari oda tanımı.
3. Rate plan — cancellation, meal ve ticari koşullar.
4. Inventory state — tarih bazlı quantity/closure.
5. Offer — belirli arama context'i için bookable sonuç.
6. Availability evidence — offer'ın ne zaman doğrulandığını gösteren timestamp ve source.

Bu ayrım “oda var ama neden satılamıyor?” sorusunu debug etmeyi kolaylaştırır.

Freshness metadata tutun

Her availability kararında gözlem zamanını tutmak değerlidir. Örnek alanlar:

• availability_checked_at,
• supplier response timestamp,
• provider/source,
• query signature,
• cache age,
• timeout/fallback flag.

Freshness bilgisi yoksa stale veri ile gerçek business-rule rejection birbirinden ayırt edilemez.

Takip edilmesi gereken KPI'lar

Sadece API success rate yeterli değildir. Şunları da izleyin:

• en az bir available offer dönen search oranı,
• unavailable-after-click oranı,
• stale availability oranı,
• availability response latency,
• click anındaki cache age,
• room/rate closure mismatch,
• provider bazlı sold-out click oranı.

Meta Search yorumu

Inventory supply modelidir; availability ise tarih, occupancy, restriction ve güncel stoğun bu modele uygulanmasıyla oluşur. Bu ayrımı koruyan metasearch sistemleri false-positive offer'ları daha iyi azaltır, sold-out click nedenini açıklayabilir ve doğru cache politikasını seçebilir.

State machine ile farkı görünür hale getirin

Inventory ve availability ayrımını operasyonel hale getirmek için room-date state'i açık modelleyin:

CONFIGURED
   |
inventory > 0
   v
SELLABLE_STOCK
   |
rate open + restrictions pass
   v
SEARCH_ELIGIBLE
   |
occupancy / itinerary valid
   v
AVAILABLE_OFFER
   |
booking
   v
INVENTORY_DECREMENT

Her adım ayrı failure nedeni üretir. "No availability" tek reason olarak kullanılırsa root cause kaybolur.

Availability evidence neden saklanmalı?

Offer ile birlikte:

• checked_at,
• provider,
• inventory snapshot/ref,
• restriction result,
• occupancy context,
• fallback flag

tutulursa sold-out click sonradan açıklanabilir.

Failure mode'lar

• inventory 0 ama stale offer gösterilmesi,
• rate açık fakat room closed,
• min-stay uygulanmaması,
• child occupancy yanlış normalize edilmesi,
• booking sonrası stock update gecikmesi,
• provider farklı timezone ile date close etmesi.

KPI'lar

• searches with available offer,
• unavailable-after-click,
• sold-out by cache-age bucket,
• inventory update latency,
• restriction rejection distribution,
• booking-to-inventory-update delay.

Availability bir boolean değil, context + evidence + timestamp ile verilmiş karardır.