Multi-Tenant Mimari Nedir? E-Ticarette 4 Farklı Yaklaşım

Mağazanızın Komşusu Kim?

Shopify'da bir mağaza açtığınızda verileriniz başka mağazalarla aynı veritabanını paylaşıyor. Siparişleriniz, müşteri bilgileriniz, ürün kataloğunuz, hepsi dev bir veritabanında diğer binlerce mağazanın verileriyle yan yana duruyor. Her satır bir "tenant_id" sütunuyla ayrılıyor. Bu mimari kararın sizin için ne anlama geldiğini platformların çoğu açıkça anlatmıyor.

Multi-tenant mimari, yazılım dünyasının en temel kararlarından biri. Bir platformun bunu nasıl çözdüğü, verilerinizin güvenliğini, sitenizin hızını ve gelecekte ne kadar özelleştirme yapabileceğinizi doğrudan etkiliyor.

Apartman Analojisi

Multi-tenant mimarisini bir apartman gibi düşünün. Tek bina, birçok daire. Her daire ayrı bir kiracıya ait. Asansör, su tesisatı, elektrik altyapısı ortak. Ama her dairenin kapısı kilitli ve içi farklı döşenmiş.

Yazılımda "bina" sunucu ve veritabanıdır. "Daireler" farklı müşterilerin verileri. Soru şu: bu daireler ne kadar birbirinden ayrı? Sadece kapı kilidi yeterli mi, yoksa tamamen ayrı binalarda mı olmalı? Bu sorunun cevabı 4 farklı mimari yaklaşım doğuruyor.

Yaklaşım 1: Paylaşımlı Veritabanı, Paylaşımlı Şema

Nasıl Çalışır?

Tek veritabanı, tek tablo yapısı. Her satırda tenant_id sütunu var. Uygulamanın her sorgusu bu sütunu filtreleyerek sadece ilgili müşterinin verilerini döndürüyor.

Ne Zaman Mantıklı?

En düşük maliyetli yaklaşım. Tek veritabanı yönetmek, tek şema güncellemek yeterli. Yeni müşteri eklemek saniyeler sürüyor. Shopify, Ikas ve Ticimax bu modeli kullanıyor. Binlerce müşteriye hizmet vermeniz gerektiğinde ve müşteriler arasında derin özelleştirme farkı olmadığında iyi çalışıyor.

Nerede Sorun Çıkar?

Bir müşterinin ağır sorgusu diğer herkesin performansını düşürebiliyor. Buna "gürültücü komşu" (noisy neighbor) problemi deniyor. Black Friday'de büyük bir mağaza yoğun trafik aldığında, aynı veritabanındaki küçük mağazalar da yavaşlayabiliyor.

İzolasyon tamamen uygulama katmanında. Bir geliştirici WHERE clause'a tenant_id filtresi eklemeyi unutursa, başka müşterilerin verilerine erişim riski doğuyor. Teorik mi? 2023'te bilinen bir e-ticaret platformunda tam da bu hata yaşandı.

Yaklaşım 2: Paylaşımlı Veritabanı, Ayrı Şemalar

Tek veritabanı sunucusu, ama her müşteri kendi şemasına sahip. İlk yaklaşıma göre daha iyi izolasyon. Yedekleme müşteri bazında yapılabilir, bu büyük avantaj.

Fiziksel kaynaklar hâlâ paylaşımlı. Şema sayısı arttıkça yönetim karmaşıklaşıyor. 500 müşteriniz varsa 500 şemanın migration'ını yönetmeniz gerekiyor. Veritabanı sunucusunun kendisi hâlâ tek nokta; o düşerse herkes düşüyor.

Orta ölçekli SaaS ürünlerinde yaygın bir tercih. İzolasyon ve maliyet arasında makul bir denge sunuyor.

Yaklaşım 3: Müşteri Başına Ayrı Veritabanı

Her müşterinin kendi veritabanı var ama uygulama kodu ortak. İyi düzeyde izolasyon sağlıyor. Bir müşterinin veritabanını bağımsız olarak yedekleyebilir, taşıyabilir ve ölçekleyebilirsiniz.

Maliyet artıyor, bu kaçınılmaz. 100 müşteri demek 100 veritabanı demek. Her birinin bakımı, yedeklemesi ve migration'ı ayrı iş. Yeni bir özellik eklediğinizde tüm veritabanlarında migration çalıştırmanız gerekiyor. Otomasyonla çözülebilir ama basit bir iş değil.

Veri izolasyonu kritik olan sektörlerde (sağlık, finans) tercih ediliyor. KVKK gibi düzenlemeler açısından da avantajlı çünkü her müşterinin verisi fiziksel olarak ayrı.

Yaklaşım 4: Fork-and-Deploy

Nasıl Çalışır?

Her müşteri kendi kod tabanına ve kendi altyapısına sahip oluyor. Ortak bir kaynak kod deposundan fork alınıyor, müşteriye özel geliştirmeler yapılıyor ve müşterinin kendi sunucusuna deploy ediliyor. Veritabanı, uygulama sunucusu, dosya depolama, her şey bağımsız.

Ne Zaman Mantıklı?

Tam izolasyon gerektiğinde. Bir müşterinin sitesi yoğun trafik aldığında başka hiçbir müşteri etkilenmiyor. Özelleştirme gerçek anlamda sınırsız: iş mantığı, veri modeli, sipariş akışı, tasarım, her şey o müşteriye özel olabiliyor.

Müşteriler arası derin farklılaşma gerektiren iş modelleri için doğru tercih. Bir lojistik firmasıyla bir moda markasının ihtiyaçları temelden farklıysa, aynı şemayı paylaşmaları zaten anlamsız.

Dürüst Değerlendirme: Riskler

Bu modelin bedeli var ve bunu gizlemenin anlamı yok. Yeni bir özellik geliştirdiğinizde bunu diğer müşterilere "otomatik olarak" dağıtamıyorsunuz. Her fork'u ayrı güncellemeniz gerekiyor. Git merge conflict'leri kaçınılmaz. Müşteri sayısı arttıkça operasyonel yük de artıyor.

100 müşteriniz varsa 100 ayrı deployment yönetiyorsunuz. Bunu otomatize etmek mümkün ama SaaS modelindeki "bir yere deploy et, herkes kullansın" kolaylığından çok farklı bir dünya.

Bu model 10-50 müşteri bandında en iyi çalışıyor. 10.000 müşteriye hizmet vermeniz gerekiyorsa muhtemelen 1. veya 3. yaklaşım daha mantıklı.

Mimari kararlar geri dönülmesi en zor kararlardır. Platform seçerken "kaç tema var" değil, "verim kimin sunucusunda, kodumu değiştirebilir miyim" diye sorun.

4 Yaklaşımın Karşılaştırma Tablosu

Her yaklaşımı 5 kriterde değerlendirelim:

Veri izolasyonu: 1. yaklaşım düşük, 2. orta, 3. yüksek, 4. tam. Özelleştirme kapasitesi: 1. ve 2. sınırlı, 3. orta (veri seviyesinde), 4. sınırsız. Operasyonel karmaşıklık: 1. en düşük, 2. düşük, 3. orta, 4. en yüksek. Müşteri başına maliyet: 1. en düşük, 2. düşük, 3. orta, 4. en yüksek. Ölçeklenme (müşteri sayısı): 1. binlerce, 2. yüzlerce, 3. yüzlerce, 4. onlarca.

Hiçbir yaklaşım diğerinden "daha iyi" değil. Her birinin doğru olduğu bir senaryo var.

Kodvex Neden 4. Yaklaşımı Seçti?

Kodvex'in hedef müşterisi belli: iş akışlarına özel bir platform isteyen, verilerinin kendi kontrolünde olmasını önemseyen, rakiplerinden farklı görünmek ve farklı çalışmak isteyen işletmeler. Bu müşteri profili için fork-and-deploy modeli mantıklı.

• Müşteri verisi asla paylaşılmıyor. Her müşterinin PostgreSQL veritabanı kendi sunucusunda çalışıyor
• Başka bir müşterinin trafiği sitenizi etkilemiyor. Altyapı tamamen bağımsız
• Gerçek özelleştirme yapılabiliyor. 18 farklı veri tipiyle envanter modelinden sipariş akışına, tasarımdan iş mantığına kadar her şey müşteriye özel

Trade-off'u kabul ediyoruz. Yeni bir özelliği tüm müşterilere aynı anda dağıtmak SaaS kadar kolay değil. Git tabanlı güncelleme sürecimiz var ama yine de SaaS'ın "deploy et, herkes kullansın" rahatlığından uzak. Karşılığında her müşteri gerçekten bağımsız bir platforma sahip oluyor.

10.000 müşteriye hizmet vermeye çalışsak bu modeli seçmezdik. Ama hedefimiz az sayıda müşteriye derin özelleştirme sunmak. Bu hedef için fork-and-deploy doğru karar.

Hazır e-ticaret ile özel yazılım karşılaştırmamız ve yazılım modelleri rehberimiz konuyu farklı açılardan ele alıyor. Teknik altyapınız hakkında konuşmak isterseniz, ücretsiz bir değerlendirme görüşmesi ayarlayalım.