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 sorunsuzca 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 diğer sistemler hep aynı sözleşmeyi kullanır. 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.
- Önceden tanımlı, sürümlenmiş API'ler
- Tek kaynak: web, mobil, B2B ve entegrasyon
- Geriye dönük uyumlu gelişim
Kesintisiz Çalışma
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 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ı
Bağımlılıkların er ya da geç arızalanacağını varsayarız. Devre kesiciler, zaman aşımları, yeniden denemeler ve kontrollü bozulma 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
- Kontrollü bozulma: çökme değil, planlı 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 (anında ya da zamanla) 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.
- Her alan için tek yetkili sahip
- Bilinçli bir tutarlılık modeli
- Denetlenebilir bir veri akışı
İzleme ve Kurtarma
İz kayıtları, metrikler ve sistem günlükleri 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 kaydı, 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 koşullarından çıkar. Bir teknik değerlendirmeyle başlayalım.