Havacılık

Yeni birinin havayolu rezervasyon sistemine baktığında yaptığı ilk çizim neredeyse her zaman aynı:

reservations
  id, passenger_name, flight_no, seat, status, created_at

Bu tablo ilk ay çalışır. İkinci ay çöker. Sebebi performans değil; PNR’ın ne olduğunu değil, neyi temsil ettiğini yanlış anlamak.

PNR ne değildir

PNR — Passenger Name Record — bir yolcunun kaydı değil. Bir seyahatin kaydı. İçinde birden fazla yolcu, birden fazla uçuş, birden fazla hizmet olabilir; ve bu parçaların her biri farklı zamanlarda, farklı taraflarca değiştirilebilir.

Somut olarak tek bir PNR şunları aynı anda taşıyabilir:

• İki yetişkin, bir bebek (bebeğin kendi koltuğu yok ama kendi bileti var)
• Gidiş İstanbul-Londra, dönüş Londra-Edinburgh-İstanbul (dönüş iki bacak)
• Bir bacağı başka bir havayolunun işlettiği kod paylaşımlı uçuş
• Ayrı satın alınmış bir bagaj hakkı ve bir koltuk seçimi
• Acentenin eklediği, havayolunun göremediği bir not

Bu yapının veri modelindeki karşılığı bir satır değil, bir ağaç. Ve ağacın dalları birbirinden bağımsız yaşıyor: bir bacağı iptal etmek diğerini iptal etmiyor, bir yolcuyu çıkarmak PNR’ı silmiyor.

Asıl mesele: PNR bir sözleşme

Modelleme hatasının kaynağı şu varsayım: “rezervasyon, sistemimdeki bir durumun kaydıdır.”

Değil. PNR taraflar arasında bir sözleşmenin şu anki hali. Taraflar: yolcu, bilet satan acente, taşıyan havayolu, ve bazen ortak havayolu. Her birinin kayıt üzerinde farklı yetkisi var ve hiçbiri tek başına sahibi değil.

Bunun üç somut sonucu var.

Birincisi: değişiklik silme değildir. Yolcu ismi düzeltildiğinde eski isim kaybolmaz. Sözleşmenin kim tarafından, ne zaman değiştirildiği kanıtlanabilir olmak zorunda — ihtilaf çıktığında bakılacak yer burası. Yani PNR’ın doğal saklama biçimi üzerine yazılan bir satır değil, eklenen bir olay günlüğü. Bunu baştan böyle kurmazsan, altıncı ayda “bu isim ne zaman değişti” sorusuna cevap veremezsin.

İkincisi: bölünme temel bir işlem. Dört kişilik bir rezervasyonda bir kişinin uçuşu değişirse, o kişi PNR’dan çıkarılıp yeni bir PNR’a taşınıyor; ikisi arasında bir bağ bırakılıyor. Buna sektörde split deniyor ve bir kenar durum değil, günlük bir işlem. Tek tablo modelinde bunun karşılığı yok.

Üçüncüsü: sahiplik devredilebilir. Acente üzerinden alınmış bir PNR’ın kontrolü havayoluna geçebilir. Kaydın “sahibi” alanı, kaydın ömrü boyunca değişen bir alan.

Neden hâlâ altı karakter

PNR’ı bulmak için kullanılan A3F9KL gibi kod — record locator — altı alfanümerik karakter. Bu sınır 1960’ların terminal ekranlarından kalma ve hâlâ duruyor, çünkü sektördeki her sistem onu bekliyor.

Pratik sonucu: bu kod benzersiz değil. Aynı locator farklı havayollarında farklı rezervasyonları gösterebilir, ve yeterince zaman geçtikten sonra aynı havayolunda bile yeniden kullanılabilir. Locator’ı birincil anahtar yapan sistemler bu yüzden yıllar sonra tuhaf çakışmalar yaşıyor.

Doğrusu şu: locator bir arama anahtarı, kimlik değil. Kimlik senin kendi sistemindeki kalıcı kimlik olmalı, locator ise dış dünyayla konuşma dili.

Ne yapmalı

Rezervasyonu bir olay günlüğü olarak modelle; bugünkü hali o günlükten türeyen bir görünüm olsun. “Şu anki durum” ayrı bir tablo olabilir ama doğrunun kaynağı olmamalı.

Ağaç yapısını gerçekten ağaç olarak kur: yolcular, bacaklar ve hizmetler ayrı varlıklar, PNR onları bir arada tutan kap. Bölme işlemini ilk sürümde desteklemesen bile, modelin buna izin verdiğinden emin ol — sonradan eklemek neredeyse yeniden yazmak demek.

Record locator’ı asla birincil anahtar yapma.

Bunların hiçbiri havacılığa özgü değil, sadece havacılıkta sonuçları daha erken görünüyor. Aynı hatayı e-ticarette sepet modellerken de yapıyoruz.

180 koltuklu uçağa 186 bilet satılıyor. Yazılımcılar bunu ilk duyduğunda hata arıyor. Hata yok — kasıt var.

Sayı neden fazla

Uçuşa gelmeyen yolcu oranı — sektörde no-show — rotaya göre değişmekle birlikte azımsanacak bir sayı değil. Esnek bileti olan iş yolcusu son anda planını değiştiriyor, aktarmalı yolcu ilk bacağı kaçırıyor, bazıları hiç gelmiyor.

Koltuk bozulabilir bir ürün: kapı kapandığı anda o koltuğun değeri sıfırlanıyor, bir daha satılamıyor. Otel odası, konser bileti, reklam gösterimi aynı kategoride.

Bu yüzden havayolu tahmini no-show oranı kadar fazla satıyor. Tahmin tutmazsa bindirme kapısında koltuk yetmiyor ve yolcu denied boarding oluyor — yani gönüllü ya da gönülsüz olarak uçuşa alınmıyor.

Kararı taşınabilir kılan şey

Burada asıl ilginç olan tazminat. Yolcunun uçağa alınmaması durumunda ödenecek bedel önceden belli ve düzenlenmiş: Avrupa’da 261/2004 sayılı düzenleme, ABD’de DOT kuralları, başka yerlerde başka rejimler. Rakam mesafeye ve gecikmeye göre değişiyor ama hesaplanabilir.

Bu tek özellik bütün modeli mümkün kılıyor. Riskin bedeli bilindiği için karar bir kumar olmaktan çıkıp bir optimizasyon problemine dönüşüyor:

beklenen kazanç = P(no-show) × ek bilet geliri
beklenen maliyet = P(fazla yolcu) × tazminat + itibar maliyeti

Havayolu ikincisini birincisinden küçük tutacak kadar fazla satıyor. Fazlası değil.

Yazılım tarafında ne değişiyor

Buradan çıkan mimari sonuçlar, havacılıkla ilgilenmesen bile işine yarayan türden.

Envanter sayacı tek bir sayı olamaz. Satılabilir koltuk sayısı fiziksel koltuk sayısı değil; sınıfa, tarifeye ve tahmine göre hesaplanan türev bir değer. Sisteminde available_seats diye tek bir alan varsa modelin daha baştan yanlış.

Fazla satış bir istisna değil, normal akış. Bindirme sürecinin gönüllü arama, yükseltme, yeniden yönlendirme ve tazminat adımlarını rutin olarak desteklemesi gerekiyor. Bunları “hata durumu” olarak kodlarsan, yılda binlerce kez çalışan bir hata yolun olur — ve hata yolları hep en az test edilen yollardır.

Karar anı geç olmalı. Kimin uçağa alınmayacağı bilet satışında değil, kapıda belli oluyor. Yani sistem son ana kadar kararsız kalabilmeli; erken bağlanan bir tasarım burada işe yaramıyor.

Neden e-ticarette aynısı yapılmıyor

E-ticarette stoktan fazla satmak — oversell — hata sayılıyor ve haklı olarak. Aradaki fark modelde değil, tazminatın fiyatlanabilir olmasında.

Havayolunda yolcuya ne ödeneceği kanunla belli. E-ticarette sipariş iptal edildiğinde müşterinin kaybı düzenlenmiş değil; maliyet tamamen itibar tarafında ve ölçülemiyor. Ölçemediğin riski optimize edemezsin.

Bu yüzden e-ticaret sistemleri stoğu rezervasyonla koruyor: sayaç azaltmak yerine süreli bir söz veriyor. Aynı problemin, tazminatın hesaplanamadığı durumdaki çözümü bu.

İki alan aynı soruyu soruyor: bozulabilir bir kaynağı, talebin belirsiz olduğu bir dünyada nasıl satarsın. Cevapları farklı, çünkü yanlış cevabın bedeli birinde bilinir, diğerinde değil.