Bir B2B SaaS ürünü geliştirmek, son kullanıcıya (B2C) yönelik bir uygulama geliştirmekten çok farklı bir mühendislik disiplini gerektirir. B2C'de odak yüksek kullanıcı hacmi ve basit deneyimdir; B2B'de ise veri izolasyonu, esnek yetkilendirme, kurum içi entegrasyonlar, regülasyon uyumu ve kesintisiz hizmet (SLA) öne çıkar.
Hızla pazara çıkmak (MVP) için alınan bazı aceleci kararlar, şirket büyüdükçe ve kurumsal (enterprise) müşteriler geldikçe aşılması çok zor teknik borçlara dönüşebilir. Bu yazıda ölçeklenebilir ve güvenli bir B2B SaaS mimarisi kurarken en sık yapılan beş hatayı ve bunlardan nasıl kaçınacağınızı anlatıyoruz.
B2B SaaS mimarisini farklı kılan ne?
B2B SaaS mimarisi, tek bir yazılım altyapısının birçok kurumsal müşteriye (kiracıya) aynı anda, birbirinden izole ve güvenli biçimde hizmet verecek şekilde tasarlanmasıdır. Her müşterinin kendi kullanıcıları, rolleri, entegrasyonları ve uyum gereksinimleri vardır.
Hata 1: Yanlış multi-tenancy (çoklu kiracı) mimarisi seçmek
B2B SaaS'ın kalbi multi-tenancy mimarisidir: tek bir altyapının birden fazla kurumsal müşteri (tenant) tarafından güvenle ve izole şekilde kullanılması. En sık yapılan hata, ölçeklenme modelini analiz etmeden tek bir izolasyon yöntemine saplanmaktır. Üç temel model vardır:
| Model | Nasıl çalışır? | Artısı | Eksisi |
|---|---|---|---|
| Paylaşımlı veritabanı, paylaşımlı şema | Tüm müşteriler aynı tablolarda, tenant_id sütunuyla ayrılır | En düşük maliyet, kolay bakım | Tek bir hatalı sorgu, A şirketinin verisini B şirketine gösterebilir |
| Kiracı başına şema | Aynı veritabanında her müşteriye ayrı şema | Orta seviye izolasyon | Şema sayısı arttıkça migration karmaşıklaşır |
| Kiracı başına veritabanı | Her müşteriye ayrı veritabanı | En yüksek izolasyon ve güvenlik | Yüzlerce müşteride migration ve bakım maliyeti büyür |
Çözüm: hibrit yaklaşım. Küçük ve orta ölçekli müşterileri paylaşımlı şemada, her sorguya otomatik eklenen kiracı filtresi (global scope ya da veritabanı seviyesinde satır güvenliği) ile çalıştırın. Yüksek bütçeli ve sıkı uyum gerektiren kurumsal müşterilere ise müstakil veritabanı (dedicated DB) sunun. Kiracı çözümleme katmanını baştan soyut tutarsanız, bir müşteriyi bir modelden diğerine taşımak kod değişikliği gerektirmez.
Hata 2: Esnek olmayan rol ve yetkilendirme (RBAC / ABAC) yapısı
B2C uygulamalarında yetki çoğunlukla "kullanıcı" ve "yönetici" diye ikiye ayrılır. B2B şirketlerde hiyerarşi çok daha karmaşıktır: yalnızca kendi bölgesinin verisini gören bölge müdürü, salt okunur erişimi olan denetçi, fatura onaylama yetkisi olan finans uzmanı gibi.
- Hata: Kodun içine
if (user.role == 'admin')gibi sabit (hardcoded) roller yazmak. - Çözüm: En baştan izin tabanlı bir RBAC (rol bazlı erişim kontrolü) ya da gerektiğinde ABAC (özellik bazlı erişim kontrolü) kurun. Kod, rolleri değil izinleri kontrol etsin; müşteriler kendi özel rollerini (custom roles) ve izin matrislerini oluşturabilsin. Kurumsal müşterilerin vazgeçilmezi olan SSO (SAML ya da OpenID Connect ile tek oturum açma) altyapısını da sistemin merkezine yerleştirin.
Hata 3: Entegrasyonu ve API-first yaklaşımı ihmal etmek
Kurumsal müşteriler hiçbir yazılımı ıssız bir ada gibi tek başına kullanmaz. Satın aldıkları SaaS ürününün ERP, CRM, İK ve muhasebe sistemleriyle konuşmasını beklerler.
- Hata: API'leri yalnızca kendi ön yüzünüzün ihtiyacına göre tasarlayıp dışarıya kapalı tutmak.
- Çözüm: API-first prensibini benimseyin. Platformun sunduğu her işlevin arkasında iyi dokümante edilmiş (OpenAPI / Swagger) bir REST ya da GraphQL API olsun. Müşterilerin sistemdeki olayları anlık olarak kendi sunucularına alabilmesi için webhook altyapısı sunun. Bu yaklaşımı nasıl uyguladığımızı Geliştiriciler & API sayfamızda görebilirsiniz.
Hata 4: "Sınırsız özelleştirme" tuzağına düşmek (kodu çatallamak)
Büyük bir kurumsal müşteri kazanmak harika bir histir. Ama "Bizim sürecimiz farklı, bize özel şu özelliği ekleyin" talebi karşısında kodu o müşteriye özel çatallamak (fork) en ölümcül hatalardan biridir.
- Hata: Her büyük müşteri için ayrı kod dalı (branch) açmak ve zamanla yönetilemeyen bir kod yığınına dönüşmek.
- Çözüm: Çatallanmış kod yerine feature flag'ler (özellik anahtarları) ve modüler eklenti (plugin / extension) mimarisi kurun. Müşteriye özel ayarları veritabanında tutun; çekirdek kod tabanınız her zaman tek kalsın. Bu konuda modüler monolit yazımız da yol gösterici olabilir.
Bir müşteri için kodu çatallamak bugün bir satış kazandırır; yarın tüm ürünü yavaşlatır.
Hata 5: Kiracı bazlı metrikleri ve denetim izini (audit log) unutmak
B2B SaaS'ta "Hangi müşteri sistemi ne kadar yoğun kullanıyor?" sorusunun cevabı, hem altyapı maliyetini yönetmek hem de kullanım bazlı fiyatlandırma (usage-based pricing) kurgulamak için kritiktir.
- Hata: Tüm logları ve metrikleri tek bir havuza atıp kiracı ayrımı yapamamak.
- Çözüm:
- Denetim izi (audit log): B2B müşterileri "Sistemimizde kim, ne zaman, hangi veriyi değiştirdi ya da sildi?" sorusuna cevap ister. Her işlemi kiracı bazlı ve değiştirilemez biçimde kaydedin.
- Kiracı analitiği (tenant analytics): Hangi kiracının ne kadar veritabanı alanı, API çağrısı ve işlem gücü tükettiğini ölçen izleme sistemleri kurun.
oigoworks'te bu ilkeleri nasıl uyguluyoruz?
Ürünlerimizde izolasyon modelini ürünün ihtiyacına göre seçiyoruz. oigohotel'de her otelin verisi ayrı bir veritabanında tutulur; oigodesk'te ise veriler şirket bazında izole edilir ve API anahtarları yalnızca kendi şirketinin verisine erişir. Her iki yaklaşımda da ürünler dış sistemlerle API ve webhook'lar üzerinden konuşur.
Sık sorulan sorular
Multi-tenancy nedir?
Multi-tenancy (çoklu kiracı mimarisi), tek bir yazılım altyapısının birden fazla müşteriye aynı anda hizmet vermesi ve her müşterinin verisinin diğerlerinden izole tutulmasıdır.
Paylaşımlı veritabanı mı, müşteri başına veritabanı mı?
Çok sayıda küçük müşteriniz varsa paylaşımlı veritabanı maliyet açısından avantajlıdır. Sıkı uyum ve izolasyon isteyen kurumsal müşteriler için müşteri başına veritabanı daha güvenlidir. Çoğu büyüyen SaaS için en iyi yol, ikisini birlikte sunan hibrit modeldir.
RBAC ile ABAC arasındaki fark nedir?
RBAC (rol bazlı erişim kontrolü) yetkileri kullanıcının rolüne göre verir. ABAC (özellik bazlı erişim kontrolü) ise kullanıcının, verinin ve ortamın özelliklerine (departman, bölge, saat gibi) göre karar verir; daha esnek ama kurması daha karmaşıktır.
Feature flag nedir?
Feature flag (özellik anahtarı), bir özelliği kodu değiştirmeden belirli müşteriler ya da kullanıcılar için açıp kapatmayı sağlayan yapılandırmadır. Müşteriye özel ihtiyaçları kodu çatallamadan karşılamanın temel aracıdır.
Sonuç: ölçeklenebilir B2B SaaS mimarisi esneklik demektir
Bir B2B SaaS ürünü geliştirmek yalnızca çalışan kod yazmak değil; üzerine onlarca şirketin güvenle kendi işini kurabileceği esnek bir platform inşa etmektir. Doğru bir multi-tenancy yapısı, izin tabanlı yetkilendirme, API-first tasarım, modüler mimari ve kiracı bazlı izlenebilirlikle yola çıkmak, ileride yaşanacak tıkanmaların önüne geçer.