SaaS Mimarisinde İlk Yapılan 7 Hata

1. Tenant modeli baştan tasarlanmaz

SaaS ürünlerin en pahalı hatası tenant ayrıştırmasını sonraya bırakmaktır. İlk müşteriler için tek veritabanında ortak tablolar yeterli görünür; ama şirket adedi 50'yi aştığında yetkilendirme, raporlama ve veri silme süreçleri tutarsız hale gelir.

Üç yaygın model vardır: tek veritabanı + tenant_id, tenant başına şema (schema-per-tenant) ve tenant başına ayrı veritabanı. Doğru seçim hedef müşteri segmentine bağlıdır; SMB için tek veritabanı + tenant_id, regülasyona tabi enterprise için ayrı veritabanı genellikle doğru başlangıçtır.

Modelden bağımsız olarak her sorguya tenant_id zorlayan bir orta katman şarttır. ORM seviyesinde row-level security veya middleware ile tenant kontrolü yapılmazsa, bir gün bir bug bütün müşterilerin verisini başka bir müşteriye gösterir.

2. Abonelik sadece ödeme entegrasyonu sanılır

Çoğu ekip Stripe veya iyzico'yu kurar ve işin bittiğini sanır. Oysa abonelik mimarisi paket, hak (entitlement), limit, kullanım, fatura ve yenileme olmak üzere altı katmandan oluşur.

Paket bir config değildir; ürünün her yerinde kullanılan bir state machine'dir. 'Bu kullanıcı bu özelliği görebilir mi?' sorusunun cevabı tek bir entitlement servisinden gelmelidir. Aksi halde özellik bayrakları kodun her yerine dağılır.

Limit aşımları (kullanım fazlası, üye sayısı, depolama) aboneliği bozmadan ele alınmalıdır. Sert kapı (hard block) yerine yumuşak uyarı + upgrade önerisi daha iyi dönüşüm verir. Bu mantığı API gateway'de değil ürün katmanında planlamak gerekir.

3. Yetkilendirme tek bir rol alanına sıkıştırılır

Erken aşamada "admin / user" şeklinde tek role alanı kurulur. Müşteriler büyüdükçe "finans rolü", "sadece okuma", "departman yöneticisi" gibi talepler gelir; mimari buna hazır olmayınca her yeni rol veritabanı şemasında bayrak eklemeye dönüşür.

Doğru yapı RBAC (Role-Based Access Control) veya daha esnek senaryolarda ABAC (Attribute-Based)'tır. Roller, izinler ve kaynak tipleri ayrı tablolarda tutulur; uygulama katmanı her isteği can(user, action, resource) şeklinde sorgular.

Bu yapıyı ilk günden kurmak zor değildir; sonradan eklemek tüm endpoint'leri ve UI'ı yeniden yazmak demektir. SaaS'ın olgunlaşmadan önce yetkilendirme katmanı kurulmuş olmalıdır.

4. Admin paneli ürünün arka ofisi olarak görülmez

Müşteri yüzü gören ürün arayüzüne emek harcanır; ama destek, onboarding, finans ve operasyon ekipleri için admin paneli sonradan eklenir. Sonuç: müşterinin kaydedilmesi, planının değiştirilmesi, abonelik iadesi gibi günlük operasyonlar veritabanına SQL ile yapılır.

Bu, hem hata riski hem zaman kaybıdır. Bir destek talebi 3 saatte değil 30 saniyede çözülmelidir. Admin paneli; tenant arama, kullanıcı taklit etme (impersonation), plan değiştirme, fatura oluşturma, log inceleme gibi operasyonel sözleşmeyi tek yerde toplar.

Doğru kurulmuş bir admin paneli destek SLA'sını yarıya indirir. Üstelik mühendislik ekibinin operasyonel taleplerle vakit kaybetmesinin önüne geçer; ürün hızı korunur.

5. Erken mikroservise geçilir

İlk müşteri kazanılmadan önce "ölçeğe hazır olalım" diye sistem 6-7 mikroservise bölünür. Sonuç: deployment karmaşası, iletişim hatası, gözlemlenebilirlik problemi ve kod tekrarı. Ürün hızı yarıya iner, problem çözme süresi 3 katına çıkar.

Modüler monolit 2026'da çoğu SaaS için doğru başlangıçtır. Tek deployment, modüller arası net sınırlar (domain klasörleri), iyi tanımlanmış public API'ler. Ölçek geldiğinde bir modül kolayca servise çıkarılır.

Mikroservise geçiş kararı performans, organizasyon büyüklüğü ve veri sınırlarıyla verilmelidir; mimari heves ile değil. Pek çok başarılı SaaS (Basecamp, GitHub, Shopify) yıllarca tek monolitle ölçeklendi.

6. Gözlemlenebilirlik (observability) sonraya bırakılır

İlk versiyon canlıya çıktığında log'lar console'a, metrikler hiçbir yere yazılmaz. Bir hata olduğunda "hangi tenant, hangi endpoint, hangi sorgu yavaş?" sorusu cevapsız kalır. Postmortem yapılamaz; ürün ekibi karanlıkta uçar.

Üç temel sütun ilk günden kurulmalıdır: structured log (JSON formatında, tenant_id + user_id + request_id ile), metrik (request latency, error rate, queue depth) ve distributed tracing (Sentry, Datadog, OpenTelemetry).

Bunlar lüks değil; SaaS'ın hava trafik kontrolüdür. Eksik gözlemlenebilirlik, en küçük bir kesintide bile saatler süren manuel inceleme demektir.

7. Veri taşıma (migration) ve şema versiyonlaması planlanmaz

İlk yıl şema değişikliği elle yapılır: prod veritabanına bağlanıp ALTER TABLE çalıştırılır. Üçüncü ay bir migration tablo kilitler; canlı sistem 20 dakika düşer. Sonraki sefer kimse migration'a güvenmez ve yeni özellikler ertelenir.

Doğru kurgu: her şema değişikliği versiyonlu migration dosyası olarak repository'de yer alır (Prisma Migrate, Flyway, Alembic). Geriye dönük uyumlu (backward compatible) yazılır; yeni kolon önce nullable eklenir, kod güncellenir, sonra zorunluya alınır.

Büyük tablolarda kilit önleyici stratejiler: online schema change araçları (gh-ost, pt-online-schema-change), partition'lama, asenkron backfill. Bunlar sonradan eklenebilir ama prensibin ilk günden olması şart: migration güvenli olmalı, yoksa hiç yapılmaz.

Sonuç: hatalar mimari değil, kararsızlık problemidir

Bu yedi hata teknik beceriksizlik değil, karar erteleme sonucudur. "İlk müşteriye ulaşalım, sonra düzeltiriz" tutumu kısa vadede hızlı görünür ama 6-12 ay sonra ekibin yarısını yeniden yazma işine bağlar.

Doğru yaklaşım: tenant, yetkilendirme, abonelik, admin, gözlemlenebilirlik ve migration için en basit çalışan versiyonu ilk günden kurmaktır. Optimize etmek değil; varlığını garantilemek. SaaS'ın olgunlaşmasıyla bu altı katman doğal olarak büyür; eksik olduğunda ürün büyümez.

Eğer bir SaaS başlatıyorsanız ve mimari kararlarınızı netleştirmek istiyorsanız, SaaS geliştirme sayfamız üzerinden iletişime geçebilirsiniz.

İlgili hizmetler

SaaS Geliştirme

Şehir bazlı landing page'ler

İstanbul Ankara İzmir Bursa

İlgili yazılar

Aynı kararı destekleyen diğer yazılar

Yazılım Kalitesi

Benzer bir proje planlıyorsanız, bağlamınızı netleştirip teklif akışını birlikte kurabiliriz.

Proje talebi oluştur