Rezervasyon Yazılımında Kapasite ve İptal Akışları

Kapasite koltuk, oda, araç veya uzman zamanı olabilir. Aynı rezervasyon birden fazla kaynağı tüketiyorsa hepsinin uygunluğu değerlendirilmelidir. Bir etkinlikte kişi sayısı; randevuda ise görevli ve hizmet süresi kapasiteyi farklı etkiler.

Başlangıç ve bitiş sınırlarını, hazırlık aralığını ve hizmetler arası boşluğu tanımlayın. 10.00–11.00 aralığı ile 11.00’de başlayan rezervasyonun çakışıp çakışmadığı sistemde tutarlı olmalıdır. İşletme takvimi, tatiller ve bakım için kapatılan dönemler aynı modele işlenmelidir.

Tek bir “başarılı” alanı yerine yer ayırma ve ödeme durumlarını ayrı izleyin. Ödeme beklenirken geçici tutma uygulanıyorsa son kullanma zamanı ve süre dolduğunda kapasitenin nasıl serbest bırakılacağı açık olsun.

Temsili bir seansın kapasitesi 12, onaylı katılımı 8 ve süresi dolmamış geçici tutması 3 ise kalan yer 1’dir. Bu hesapta aynı kaydı hem onaylı hem geçici tutulan olarak saymayın. Süresi dolan tutmaların ne zaman hesap dışına çıkacağı belirli olsun.

İki kullanıcının aynı anda 1 boş yer görmesi mümkündür. Son karar yalnızca tarayıcıdaki sayıya bırakılamaz. Kontrol ve yer ayırma sunucuda tutarlı bir işlem olarak yapılmalı; veritabanı kısıtları, kilitleme veya uygun izolasyon yaklaşımı veri modeline göre seçilmelidir. Çakışma halinde uygulamanın tekrar deneme ve kullanıcı mesajı davranışı da tanımlansın.

Geçici tutma süresi dolduktan sonra ödeme bildirimi gelirse doğrudan onay vermek fazla rezervasyon yaratabilir. Önce yerin hâlâ ayrılıp ayrılamayacağını doğrulayın. Ayrılamıyorsa işletmenin tanımladığı inceleme ve iade sürecini başlatın; kullanıcıya tamamlandı bilgisi vermeyin.

Aynı bildirim tekrar geldiğinde rezervasyonu veya iadeyi ikinci kez oluşturmayın. Sağlayıcı bildirimini doğrulayın ve işlem referansını kaydedin. Rezervasyon iptalinin kaydedilmesi ile ödeme sağlayıcısındaki iadenin tamamlanması ayrı olaylardır; her ikisinin durumu izlenebilsin.

Kullanıcı, işletme ve sunucu farklı saat dilimlerinde olabilir. Rezervasyonun hangi yerel takvime ait olduğunu ve zamanın nasıl saklandığını tanımlayın. Kullanıcıya görünen saatle hatırlatma mesajındaki saatin aynı anlamı taşıdığını doğrulayın.

Uluslararası kullanım varsa yaz/kış saati geçişindeki tekrarlanan veya hiç oluşmayan saatleri test edin. İptal için “bir gün önce” ifadesi kullanılacaksa takvim günü mü belirli saat farkı mı kastedildiğini iş kuralında açıklayın. Zamanlayıcı geciktiğinde tutma süresinin sunucuda yeniden kontrol edilmesi gerekir.

Arayüzde peş peşe iki tıklama yapmak gerçek eşzamanlılık testinin yerini tutmayabilir. Aynı kaynağa aynı anda talep gönderildiğinde toplam ayrılan kapasitenin sınırı aşmadığını kontrollü test ortamında doğrulayın.

MVP kapsamı rehberi ile ilk sürüm sınırını; kabul testleri ile bu akışın tamamlanma koşullarını belirleyin. Dış ödeme veya takvim bağlantıları için API entegrasyonu kapsamındaki hata ve tekrar kurallarını kullanın.