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.

DEV Community: Ali şahin BALCIOĞLU