Monolitik Frontend’den Next.js Multi-Zone Mimarisine Geçiş (Monolitik Frontendden Nextjs Multi Zone Mimarisine Gecis)

Referans notu

Bu seri, gerçek üretim sistemlerinde edinilmiş mühendislik deneyimlerinden türetilmiş kararları ve tasarım yaklaşımlarını paylaşır. Kamuya açık olmayan kaynak kodu, müşteri verisi, altyapı yapılandırmaları veya şirket içi operasyonel bilgiler yer almaz. Örnekler, gizlilik yükümlülüklerine uygun biçimde genelleştirilmiş veya anonimleştirilmiştir.

Başlangıçtaki problem

Monolitik frontend kötü bir başlangıç değildir. Tek ekip, ortak bir teslimat ritmi ve sınırlı ürün yüzeyi için en düşük operasyon maliyetini taşır. Gerilim; katalog, arama, sepet, ödeme, hesap ve satıcı deneyimleri aynı kod tabanında farklı hızlarda değişmeye başladığında oluşur.

Tek frontend
  → ortak derleme kuyruğu
  → ortak release penceresi
  → ilgisiz değişikliklerin birbirini beklemesi

İş alanları
  → farklı değişim ritimleri
  → farklı hata etkileri
  → farklı ölçek ihtiyaçları

Bu yazının sorusu Multi-Zone nasıl kurulur değildir. Asıl soru şudur: Hangi kanıt, frontend sınırını bölmenin ek maliyetinden daha değerlidir?

Kavramlar ilk geçtiği yerde

📦 Zone
Belirli bir URL alanından ve kullanıcı niyetinden sorumlu, bağımsız dağıtılabilen istemci uygulaması.

📦 Gateway
Tarayıcının tek bir alan adı altında gördüğü giriş katmanı; isteği doğru zone'a iletir.

📦 Independent deployment
Bir alanın değişikliğini, ilgisiz alanların release penceresine bağlamadan canlıya alma disiplini.

📦 Blast radius
Bir hata veya değişikliğin etkileyebileceği kullanıcı ve sistem alanı.

Zone, yalnızca klasörleri ayırmak değildir. Sahiplik, deploy, gözlemlenebilirlik ve geri alma kararını da ayırır. Bu nedenle teknik sınır; ürün niyeti ve ekip sorumluluğu ile birlikte çizilmelidir.

Problem: monolith neden bir gün yavaşlar?

Bir marketplace büyüdükçe her alan kendi ritmini üretir. Arama ekibi filtreleme ve indeks davranışını sık değiştirir. Sepet ve ödeme tarafı daha yüksek güven ve daha kontrollü release ister. Satıcı araçları ise müşteri deneyiminden bağımsız teslim edilebilir olmalıdır. Hepsini aynı deploy birimine koymak, kod paylaşımı değil; koordinasyon paylaşımı yaratır.

Katalog değişikliği ─┐
Arama deneyi       ├─ aynı build ve release kuyruğu
Ödeme düzeltmesi   ┘

Sorun dosya sayısı değildir. Bir iş alanındaki riskin, başka bir alanın teslimat hızını belirlemesidir.

Alternatifler: karar öncesi seçenekler

Alternatif	Güçlü yanı	Kabul edilen bedel
Tek uygulama	En basit yerel geliştirme	Ortak release ve büyüyen etki alanı
Module Federation	Runtime modül paylaşımı	Versiyon, runtime bağımlılığı ve hata ayıklama maliyeti
Next.js Multi-Zone	URL alanına göre bağımsız deploy	Routing, asset ve cross-zone sözleşme disiplini
Tam ayrı alan adları	Güçlü izolasyon	Kullanıcı deneyimi, oturum ve SEO parçalanması

Multi-Zone kararı, module paylaşımı ihtiyacından değil; bağımsız değişim ve tek kullanıcı yüzeyi ihtiyacının aynı anda oluşmasından doğar. Tarayıcı tek ürün görür. Ekipler, sorumluluğu net istemci alanları görür.

Karar: URL sınırını iş sınırıyla eşlemek

Her zone bir URL alanını, onun kullanıcı niyetini ve release sorumluluğunu sahiplenir. Gateway yalnızca doğru isteği doğru uygulamaya yönlendiren bir bileşen değildir; sistemin dışarıdan tek ürün görünmesini sağlayan sınırdır.

Browser
  → Gateway
    → Catalog zone
    → Search zone
    → Cart and checkout zone
    → Account zone

Her zone
  → kendi deploy kararı
  → kendi health sinyali
  → açık route sözleşmesi

Route sahipliği tek bir kayıt altında tutulmalıdır. Aksi hâlde iki zone aynı URL'yi sahiplenir, locale davranışları ayrışır veya redirect zincirleri görünmez biçimde büyür. URL eşleme aramasının ortalama maliyeti O(1) olsa da asıl maliyet çalışma zamanındaki belirsizliktir; bu yüzden route sözleşmesi test edilmelidir.

Trade-off: bağımsızlık ücretsiz değildir

Multi-Zone; daha fazla repository açmak veya her sayfayı ayrı uygulamaya taşımak değildir. Yeni her zone; build, deploy, health check, rollback, güvenlik politikası ve sahiplik maliyeti ekler. Cross-zone state için de tek bir global istemci mağazasına güvenmek yerine, sunucu kaynağını otorite kabul eden açık sözleşmeler gerekir.

Örnek olarak sepet sayacı, oturum yenileme veya dil tercihi zone'lar arasında görünür olmak isteyebilir. Bu veri için doğru soru hangi pakette tutulacağı değil; kaynağın kim olduğu, güncellemenin ne zaman geçerli sayıldığı ve hata halinde nasıl toparlanacağıdır.

Production'da ortaya çıkan gerçek gerilimler

1. Asset izolasyonu: Her zone kendi bundle'ını üretir. Statik dosya adresleri ve önbellek politikaları çakışmaz biçimde tasarlanmalıdır.
2. Routing ve locale: Gateway, dinamik path ve dil öneklerini tek bir sözleşme üzerinden iletmelidir.
3. Oturum: Kimlik doğrulama tarayıcıda parçalı deneyim üretmemeli; token yenileme ve logout davranışı zone sınırında test edilmelidir.
4. Geri alma: Bağımsız deploy, bağımsız rollback gerektirir. Bir zone sürümü geri alındığında route ve API contract uyumu korunmalıdır.
5. Gözlemlenebilirlik: Bir kullanıcı isteği birden fazla zone'dan geçiyorsa correlation id, hata oranı ve route düzeyinde metrikler görünür olmalıdır.

Bugün yeniden tasarlasam

Daha erken küçük zone'lar üretmezdim. Önce route sahipliğini, ekip bağımsızlığını ve ölçülebilir release sürtünmesini kanıtlardım. Paylaşılan UI, auth, types ve utilities paketlerini dar ve sürümlenebilir tutardım; paylaşılan package kolaylık için sınırsız ortak alan hâline gelirse yeni bir monolith üretir.

İlk hedef, en fazla zone değil; en düşük koordinasyon maliyeti olurdu.

Sık karıştırılanlar

❌ Multi-Zone = her sayfa için ayrı uygulama
✓ Zone, bağımsız değişen bir kullanıcı niyeti ve sahiplik sınırıdır.

❌ Multi-Zone = otomatik micro frontend başarısı
✓ Route, asset, session ve rollback sözleşmeleri bilinçli tasarlanmalıdır.

❌ Shared package = her şeyi ortaklaştırmak
✓ Shared package, stabil ve gerçekten ortak olan contract'lar içindir.

❌ Bağımsız deploy = koordinasyonsuz deploy
✓ Bağımsızlık, açık contract ve daha iyi operasyon disiplini ister.

Karar kontrol listesi

1. Bu alanın kullanıcı niyeti, sahibi ve release ritmi diğerlerinden gerçekten farklı mı?
2. Bir hata olduğunda blast radius küçülüyor mu?
3. Zone'un route, locale ve asset sınırı açık mı?
4. Session ve cross-zone state için otorite kaynağı belli mi?
5. Her zone'un rollback, health ve gözlemlenebilirlik sinyali var mı?
6. Bu kararın Module Federation veya modüler monolith karşısındaki maliyeti açıkça yazıldı mı?

Bir sınır yalnızca deploy süresini değil; test, incident ve karar maliyetini de azaltıyorsa değerlidir.

Bu yazıdan aklında ne kalmalı

Multi-Zone'ın amacı frontend'i parçalamak değil; değişimin etkisini doğru sınıra hapsetmektir.

Monolith uzun süre doğru seçim olabilir. Ayrışma, ancak bağımsız değişim, hata izolasyonu ve kontrollü teslimat ihtiyacı birlikte kanıtlandığında anlamlıdır.

Bir sonraki bölümde alternatif kararın derinine ineceğiz: Neden Module Federation Değil?