DEV Community: Ali şahin BALCIOĞLU

Saha Operasyonunda Canlı Konum Takibi: Gerçek Zamanlı Görünürlük Nasıl Kurulur

Ali şahin BALCIOĞLU — Thu, 01 Oct 2026 06:03:43 +0000

Saha operasyonu yürüten firmalarla konuştuğumuzda hep aynı cümleyle başlıyor sohbet: "Şoförün nerede olduğunu bilmiyoruz." İlk bakışta küçük, günlük bir operasyonel rahatsızlık gibi görünüyor. Oysa bu tek cümlenin arkasında üç ayrı kör nokta birikiyor: görünürlük, hakediş ve denetim. Birini çözmeden diğer ikisi de çözülmüyor, çünkü üçü aynı veri eksikliğinden besleniyor.

Bu yazıda bir personel servis yönetim sistemi üzerinde geliştirdiğimiz canlı konum takibi altyapısından yola çıkarak, saha operasyonunda gerçek zamanlı görünürlüğü nasıl kurduğumuzu anlatıyoruz.

Görünürlük eksikliği aslında nerede başlıyor

Çoğu firma personel taşımacılığı, saha ekibi sevkiyatı ya da kurumsal ulaşım gibi operasyonları hâlâ WhatsApp grupları ve elle tutulan Excel dosyalarıyla yönetiyor. Şoför bir gruba "yola çıktım" yazıyor, bir süre sonra "vardım" yazıyor. İkisi arasında geçen süre bir kara kutu. Sefer gecikti mi, nerede gecikti, kaç dakika durdu — bunların hiçbiri kayıt altında değil.

Bu durumda üç şey aynı anda bozuluyor. Birincisi görünürlük: yöneticinin elinde o anki durumu gösteren bir ekran yok, sadece mesaj geçmişi var. İkincisi hakediş: acenteye ya da şoföre ne kadar ödeneceği, gerçekleşen sefere değil, beyan edilen sefere göre hesaplanıyor. Üçüncüsü denetim: bir ihlal (geç kalkış, güzergah dışına çıkma, durak atlama) yaşandığında bunu kanıtlayacak bir iz yok, sadece karşılıklı anlatılan hikâyeler var.

Canlı konum takibi aslında ne çözüyor

Geliştirdiğimiz sistemde şoför mobil uygulaması konum verisini düzenli aralıklarla sunucuya gönderiyor, sunucu bu veriyi Socket.io üzerinden yönetim paneline ve ilgili acente paneline anlık olarak yayıyor. Burada teknik tercih önemli: anlık yayın için klasik istek-cevap (REST polling) yerine soket tabanlı bir bağlantı kullanmak gerekiyor, çünkü her birkaç saniyede bir "şimdi neredesin" diye sormak hem sunucuyu hem de mobil cihazın pil ömrünü gereksiz yere yoruyor.

Konum verisinin kendisi kadar, bu veriyle ne yapıldığı da önemli. PostGIS kullanarak coğrafi sorguları veritabanı katmanında çalıştırıyoruz: bir aracın belirlenen güzergahtan ne kadar saptığı, bir durağa ne zaman yaklaştığı, bir bölgeye giriş-çıkış yaptığı gibi sorular, uygulama katmanında değil veritabanında cevaplanıyor. Bu, hem performans hem de doğruluk açısından fark yaratıyor — binlerce konum noktasını uygulama tarafında karşılaştırmak yerine, veritabanının bunun için tasarlanmış fonksiyonlarını kullanıyorsunuz.

Çok kiracılı yapılarda görünürlük daha da karmaşıklaşıyor

Tek bir şoförün konumunu göstermek nispeten kolay bir problem. Gerçek zorluk, aynı sistemde birden fazla tarafın aynı anda, ama birbirinin verisini görmeden çalışması gerektiğinde ortaya çıkıyor. Geliştirdiğimiz sistemde 13 farklı taşıma acentesi aynı platformu kullanıyor; her acente kendi şoförlerini, kendi seferlerini ve kendi hakedişini görüyor, ama başka bir acentenin verisine erişemiyor.

Bu izolasyonu arayüzde bir filtre olarak değil, backend katmanında bir kural olarak kurmak gerekiyor. Aksi halde bir gün bir sorgu parametresi değişir, bir acente başka bir acentenin konum verisini görür ve bu basit bir arayüz hatası değil, ciddi bir veri sızıntısı olur. Multi-tenant bir yapıda görünürlük sağlarken asıl mesele "veriyi nasıl gösteririz" değil, "veriyi kime göstermemiz gerektiğini nasıl garanti ederiz" sorusu.

Görünürlük, hakediş ve denetimi otomatikleştiriyor

Konum ve sefer verisi gerçek zamanlı ve güvenilir şekilde toplandığında, bunun üzerine iki şey doğal olarak oturuyor. Birincisi otomatik hakediş hesaplama: acente ya da şoför ödemesi, elle girilen bir rakama değil, gerçekleşen sefer verisine dayanıyor. Excel'e veri aktarma, ay sonunda uzlaşma toplantısı yapma ihtiyacı ortadan kalkıyor.

İkincisi ihlal yönetimi. Bir sefer güzergahtan saptığında ya da bir durak atlandığında bu sistemde otomatik olarak işaretleniyor ve iz bırakıyor. Bu, "o gün öyle olmadı" tartışmalarını büyük ölçüde ortadan kaldırıyor; çünkü artık karşılıklı anlatıya değil, kayıtlı veriye bakılıyor.

Bunların ikisi de aslında aynı temel fikrin uzantısı: operasyonu gözlemlenebilir hale getirdiğinizde, üzerine kurduğunuz her süreç daha az tartışmalı, daha az manuel hale geliyor.

Görünürlük güvenlikten ayrı düşünülemez

Konum verisi hassas bir veridir — bir kişinin nerede olduğunu gösterir. Bu yüzden canlı konum takibi kurarken görünürlüğü artırmakla veriyi korumak arasında bir denge kurmak gerekiyor. Sistemde OTP ile giriş, JWT token rotasyonu ve loglarda kişisel verilerin maskelenmesi gibi önlemler bu dengenin parçası. Görünürlüğü artırmak, herkesin her şeyi görmesi anlamına gelmemeli; kimin neyi ne zaman gördüğü de denetim altında olmalı.

Aynı sorun, daha büyük ölçekte

Kurumsal ölçekli ulaşım operasyonlarında bu sorun küçülmüyor, büyüyor. Araç sayısı arttıkça, güzergah çeşitliliği arttıkça, manuel takibin kırılma noktası daha hızlı geliyor. Bu tür operasyonları dijitalleştirirken kurduğumuz web ve mobil bileşenlerin ortak paydası yine aynı: operasyonun o anki durumunu, geçmişe bakmadan, canlı olarak görebilmek.

Sonuç olarak

Canlı konum takibi tek başına bir özellik değil, saha operasyonunu yöneten her sürecin üzerine oturduğu bir temel. Görünürlük olmadan hakediş tartışmalı kalıyor, denetim kanıtsız kalıyor, yönetici de operasyonu değil operasyonun anlatısını yönetmiş oluyor. Bizim bu konudaki yaklaşımımız şu: önce veriyi doğru ve güvenli şekilde gerçek zamanlı hale getirin, geri kalan süreçler — hakediş, denetim, raporlama — bu temel üzerine çok daha az sürtünmeyle oturur.

Gerçek zamanlı veri için soket tabanlı bağlantı, polling'e tercih edilmeli.
Coğrafi sorgular uygulama katmanında değil veritabanı katmanında (PostGIS gibi) çalıştırılmalı.
Çok kiracılı yapılarda veri izolasyonu backend kuralı olmalı, arayüz filtresi değil.
Görünürlük artarken veri güvenliği (OTP, token rotasyonu, PII maskeleme) aynı özenle kurulmalı.

Tek Sistemde Onlarca Acente: Multi-Tenant Mimarinin Sahadaki Karşılığı

Ali şahin BALCIOĞLU — Tue, 15 Sep 2026 09:06:46 +0000

Problem: Aynı sistem, birbirinden habersiz onlarca işletme

Personel servis taşımacılığı yürüten kurumsal operasyonlarda genellikle tek bir şirket değil, birden fazla taşıma acentesi aynı anda çalışır. Her acentenin kendi araç filosu, kendi şoförleri, kendi hakediş hesabı vardır. Bu tabloyu tek bir yazılımda birleştirmek istediğinizde karşınıza çıkan asıl soru arayüz değil şudur: acente A'nın verisi, hiçbir şekilde acente B'nin ekranına sızmamalı, ama sistem yöneticisi tüm acenteleri tek yerden görebilmeli.

Bizim geliştirdiğimiz personel servis yönetim sisteminde bu senaryoyu birebir yaşadık. Sistem, 13 farklı taşıma acentesini tek platformda barındırıyor; her biri kendi paneline giriyor, kendi sefer ve şoför verisini yönetiyor, ama hiçbiri diğerinin verisine erişemiyor. Bunu arayüzde bir filtre olarak değil, backend katmanında bir izolasyon kuralı olarak kurduk. Çünkü arayüz seviyesinde yapılan bir "gösterme" işlemi, bir API isteğiyle kolayca aşılabilir; asıl güvenlik sorgunun kendisinde, veritabanı erişim katmanında sağlanmalı.

Multi-tenant mimari neden tek çözüm gibi görünür ama değildir

Çoğu ekip "multi-tenant" dediğinde aklına gelen ilk çözüm, her müşteriye ayrı bir veritabanı açmaktır. Bu yaklaşım küçük ölçekte işe yarar ama acente sayısı arttıkça bakım yükü katlanarak büyür: her yeni acente için ayrı şema, ayrı migration, ayrı yedekleme süreci. Bizim tercih ettiğimiz yöntem, tek bir veritabanı üzerinde acente kimliğini her sorgunun zorunlu bir parçası haline getirmekti. Yani bir şoförün konum kaydını çekerken de, bir hakediş raporunu oluştururken de, sorgunun içinde "hangi acente" bilgisi her zaman var ve bu bilgi kullanıcı girdisinden değil, oturum bilgisinden geliyor.

Bu tasarımın getirdiği asıl kazanım, yeni bir acenteyi sisteme eklemenin bir altyapı işi değil, bir kayıt işi haline gelmesidir. Ölçeklenebilirlik burada teknik bir slogan değil, operasyonel bir gerçek: 13. acenteyi eklemek, 1. acenteyi eklemekten yapısal olarak farklı değil.

Roller: Görünürlük herkese aynı şekilde açılmaz

Multi-tenant bir sistemde izolasyon kadar önemli olan ikinci konu, kimin neyi görebileceğidir. Bizim kurduğumuz yapıda beş farklı rol var: süper admin, admin, acente yöneticisi, şoför ve personel. Süper admin tüm acenteleri görür ve sistem genelinde denetim yapar; acente yöneticisi yalnızca kendi filosunu ve kendi hakedişini görür; şoför yalnızca kendi seferini; personel yalnızca kendi servis kaydını. Bu ayrım basit görünse de sahada en çok tartışılan konulardan biridir, çünkü her acente "biraz daha fazla görmek" ister, sistemin bütünlüğü ise net sınırlar gerektirir.

Rol tasarımını yaparken şunu öğrendik: yetkilendirmeyi sonradan yamamak yerine, veri modelinin en başından itibaren rol bazlı düşünmek gerekiyor. Aksi halde her yeni özellik, "bunu kim görebilir" sorusunu tekrar tekrar açar ve sistem zamanla tutarsız yetki kurallarının birikimi haline gelir.

Otomatik hakediş: Excel'in bittiği yer

Çok acenteli operasyonlarda en büyük operasyonel sürtünme noktalarından biri hakediş hesabıdır. Geleneksel yöntemde her acente kendi seferlerini sayar, bir excel dosyası hazırlar, bu dosya yönetim tarafından tek tek kontrol edilir. Bu süreç hem yavaştır hem de hataya açıktır; sefer sayısı arttıkça elle kontrol imkansızlaşır.

Bizim sistemimizde hakediş hesabı, sefer verisinin kendisinden otomatik olarak türetiliyor. Bir sefer tamamlandığında, o seferin hangi acenteye ait olduğu, hangi şoför tarafından yapıldığı ve hangi durumda sonuçlandığı sistemde zaten kayıtlı; hakediş bu kayıtlardan hesaplanıyor, ayrıca bir excel dosyasına ihtiyaç duyulmuyor. Bu, sadece zaman kazandırmıyor; acente ile yönetim arasındaki "kaç sefer yapıldı" tartışmasını da ortadan kaldırıyor, çünkü herkes aynı kayda bakıyor.

İhlal yönetimi ve denetlenebilirlik

Manuel yürütülen servis operasyonlarında bir sefer ihlali (gecikme, güzergah dışına çıkma, eksik personel taşıma gibi durumlar) genellikle sözlü bir şikayetten öteye gitmez; kayıt altına alınmaz, tekrarı takip edilmez. Bizim sistemimizde ihlaller ayrı bir kayıt olarak tutuluyor ve iz bırakıyor. Bu, tek bir olayı cezalandırmak için değil, zaman içindeki örüntüyü görebilmek için önemli: bir acentenin belirli bir şoförü sürekli aynı ihlali yapıyorsa, bu bilgi ancak kayıt sistematik tutulduğunda ortaya çıkar.

Güvenlik: Çok acenteli bir sistemde güven tek noktadan kurulur

Onlarca acentenin ve yüzlerce şoförün/personelin aynı sistemi kullandığı bir yapıda kimlik doğrulama tek bir zayıf noktaya indirgenemez. Bizim yaklaşımımızda giriş OTP ile doğrulanıyor, oturum token'ları JWT rotasyonuyla yönetiliyor, yani bir token çalınsa bile ömrü sınırlı ve yenilenme mekanizması var. Loglarda ise kişisel verileri maskeliyoruz; bir hata ayıklama sürecinde bile geliştirici ekranında ham telefon numarası ya da kimlik bilgisi görünmüyor. Çok kiracılı bir sistemde bu tür önlemler lüks değil, sistemin güvenilirliğinin ön koşulu.

Sahadan çıkan ders

Multi-tenant mimari kurmanın zorluğu kodda değil, kararlarda. Hangi veri paylaşılır, hangi veri asla paylaşılmaz, yeni bir acente eklendiğinde sistemin hangi varsayımları bozulur — bu sorulara baştan net cevap vermeyen bir mimari, acente sayısı arttıkça kırılganlaşır. Biz bu projede izolasyonu backend'de, yetkilendirmeyi rol modelinde, denetimi de kayıt bütünlüğünde kurduğumuz için sistem büyüdükçe karmaşıklaşmadı, sadece genişledi.

Benzer bir çok paydaşlı operasyonu tek sistemde toplamayı düşünüyorsanız, bu deneyimi konuşmaktan memnuniyet duyarız.