Mimari sonradan düzeltilmez; baştan verilen kararların toplamıdır.
Bir sistemin yük altında nasıl davranacağı, nasıl arızalanacağı ve nasıl büyüyeceği; daha tek satır kod yazılmadan belli olur. Aşağıda, ExaRock'un yazılım mimarisi felsefesini ve her kararın ardındaki gerekçeyi paylaşıyoruz.
Monolit mi, mikroservis mi? Asıl soru bu değil.
Mikroservis bir araçtır, amaç değil. Çoğu işletme için erken mikroservis, çözdüğünden daha çok operasyonel karmaşıklık getirir. Biz, sınırları API sözleşmeleriyle tanımlanmış, net modüllere sahip bir monolitle başlarız; böylece bir modül bağımsız ölçeklenmeyi gerçekten hak ettiğinde, onu sancısızca bir servise ayırabiliriz.
- Sözleşmeyle tanımlı, net modül sınırları
- Erken karmaşıklık yerine kademeli ayrışma
- Ölçekleme ihtiyacı kanıtlandığında bölme
API-First (Önce API)
Her yetenek önce bir API sözleşmesi olarak tasarlanır; web uygulaması, mobil, B2B portalı ve üçüncü sistemler hep aynı sözleşmeyi tüketir. Bu; frontend ile backend'i paralel geliştirmeyi, entegrasyonları öngörülebilir kılmayı ve mevcut bağlantıları bozmadan sürümlemeyle büyümeyi sağlar.
- Sözleşme öncelikli, sürümlenmiş API'ler
- Tek kaynak: web, mobil, B2B ve entegrasyon
- Geriye dönük uyumlu gelişim
Yüksek Erişilebilirlik (High Availability)
Bir otel rezervasyon sezonunun ani talebi ya da gerçek zamanlı bir B2B sipariş akışının anlık yoğunluğu, sistemin en çok ihtiyaç duyulduğu anlardır. Yatay ölçeklenen servisler, durumsuz (stateless) bir uygulama katmanı, önbellekleme ve kuyruklar yükü emer; hiçbir bileşen tek başına darboğaza dönüşmez.
- Yatay ölçekleme ve durumsuz uygulama katmanı
- Yük tepe noktalarını emen önbellek ve kuyruklar
- Tek hata noktası (SPOF) olmayan bir mimari
Hata Toleransı (Fault Tolerance)
Bağımlılıkların er ya da geç arızalanacağını varsayarız. Devre kesiciler, zaman aşımları, yeniden denemeler ve zarif bozulma (graceful degradation) ile yavaşlayan bir servis tüm sistemi kilitlemez; kullanıcı, bir çökme yerine kontrollü bir yedek davranış görür.
- Devre kesici, zaman aşımı ve yeniden deneme
- Zarif bozulma: çökme değil, kontrollü yedek
- İzole arıza: bir modülün sorunu yayılmaz
Durum ve Veri Sahipliği
Her veri parçasının tek bir sahibi ve tek bir doğru kaynağı vardır; tutarlılık modeli (güçlü ya da nihai) bilinçli olarak seçilir. Bu, dağıtık sistemlerde en sık görülen 'sessiz veri tutarsızlığı' sınıfını baştan engeller.
- Sınırlı bağlam başına yetkili sahiplik
- Bilinçli bir tutarlılık modeli
- Denetlenebilir bir veri akışı
Gözlemlenebilirlik ve Kurtarma
İz (trace), metrik ve günlükler baştan tasarıma girer; böylece bir sorun, müşteriye yansımadan görülür. Kurtarma hedefleri (RTO/RPO) bir temenni değil, prova edilen ve ölçülen taahhütlerdir.
- Uçtan uca iz, metrik ve günlük
- Proaktif uyarı: sorun müşteriden önce görülür
- Prova edilmiş kurtarma (RTO/RPO)
Mimariyi, sizin gerçek yük ve risk tablonuza göre tasarlarız.
Doğru mimari bir slayttan değil, operasyonunuzun gerçek kısıtlarından çıkar. Bir teknik değerlendirmeyle başlayalım.