Turnike Sistemlerinde Geçiş Kaydı Ne Zaman Kesinleşmeli? Donanımla Tutarlı Veri Tasarımı
Mehmet Fatih İçin · · 7 dk okuma
Bir turnikenin önünde duran ziyaretçi için her şey tek bir an gibi görünür: QR'ı okut, ışık yeşile dönsün, kol dönsün. Yazılım tarafında ise bu “an” en az dört ayrı olaydan oluşur ve hangisinde bileti “kullanıldı” saydığınız, sistemin güvenilirliğini belirler. Bu yazıda, kurumsal ölçekte geliştirdiğim geçiş kontrol sistemlerinden çıkardığım yaklaşımı genel hatlarıyla anlatıyorum. Güvenlik ayrıntılarına değil, veri tutarlılığına odaklanıyorum.
Bir geçişin dört olayı
- Okuma: Okuyucu QR'ı ya da kartı okur ve kimliği gönderir.
- Doğrulama: Merkezi servis biletin geçerli olup olmadığına karar verir.
- Açma komutu: Turnikeye röle üzerinden “bir kişilik aç” sinyali gider.
- Geçiş: Kol fiilen döner ve turnike “döndü” bilgisini geri bildirir.
En sık yapılan hata, bileti 2. adımda, yani doğrulama anında kullanılmış saymaktır. Kâğıt üzerinde mantıklıdır; ama ziyaretçi okuttuktan sonra vazgeçerse, kol sıkışırsa ya da elektrik kesilirse bilet yanmış olur ve kişi kapıda kalır. Tersine, kayıt hiç tutulmazsa aynı bilet arka arkaya okutularak birden fazla kişi geçebilir.
Çözüm: rezervasyon ve kesinleştirme
Daha sağlam model, işlemi iki aşamaya bölmektir. Doğrulama anında bilet kısa süreli olarak ayrılır (ör. birkaç saniyelik bir kilit). Bu sürede aynı bilet başka bir kapıda okutulursa reddedilir. Turnike “döndü” sinyalini gönderdiğinde ayırma kesinleşir ve geçiş kaydı yazılır. Sinyal süre içinde gelmezse ayırma kendiliğinden düşer ve bilet tekrar kullanılabilir.
Bu yaklaşım iki uç durumu birlikte çözer: vazgeçen ziyaretçinin bileti yanmaz, aynı bilet de iki kişiyi geçirmez. Raporlar da “okutulan” değil “gerçekten geçen” kişiyi sayar; içerideki anlık ziyaretçi sayısı bu sayede doğru olur.
Ağ kesintisi ve tekrar eden istekler
Sahada ağ her zaman kusursuz değildir. Kapıdaki servis “döndü” bilgisini gönderir ama yanıtı alamazsa aynı isteği tekrar dener. Merkezi servis bu isteği iki kez işlerse aynı geçiş iki kez sayılır. Bunu önlemenin yolu her geçiş olayına benzersiz bir kimlik vermek ve servisi idempotent yazmaktır: aynı kimlikle gelen ikinci istek yeni kayıt oluşturmaz, ilk sonucu döndürür. Veritabanı tarafında bu, geçiş kimliği üzerinde benzersiz bir indeksle garanti altına alınır.
Donanım farklılıklarını soyutlamak
Farklı marka turnikeler, okuyucular ve röle kartları farklı protokoller konuşur. İş kuralını donanıma gömmek yerine, her kapıda donanımla konuşan ince bir “kapı servisi” ve tüm kararları veren merkezi bir API kullanmak bakımı kolaylaştırır. Yeni bir cihaz modeli geldiğinde sadece kapı servisinin sürücüsü değişir; bilet kuralları, raporlar ve entegrasyonlar etkilenmez.
Kısaca
- Bileti okuma anında değil, kol döndüğünde kesinleştir.
- Okuma ile geçiş arasında kısa süreli ayırma kullan.
- Kapıdan gelen her olaya benzersiz kimlik ver, servisi idempotent yaz.
- Donanım farklılıklarını kapı servisinde topla, iş kuralını merkezde tut.
Bu yaklaşımın gerçek bir projede nasıl uygulandığını turnike ve geçiş kontrol vaka çalışmasında okuyabilirsin. Benzer bir sistem için destek arıyorsan teklif formundan yazabilirsin.