Bir yazılım mimarisi kurarken aslında ne yapıyoruz? Geleceğe bahis oynuyoruz (şaşırtıcı ama gerçek). Hani “şimdilik böyle gitsin” dediğiniz — ki bu tartışılır — kararlar var ya — işin aslı şu ki, bazıları yıllarca sizi rahat ettiriyor, bazıları ise iki sene sonra sessiz sedasız teknik borca dönüşüyor, üstelik farkında bile olmuyorsunuz çoğu zaman. 2025’e geldiğimizde bu durum daha da görünür oldu. Ekipler artık sadece çalışan sistemi değil, sürdürülebilir sistemi de ayakta tutmak zorunda.
Geçen ay İstanbul’da bir fintech ekibiyle yaptığım sohbette tam da bu konu açıldı. Takım lideri bana “Mikroservis yaptık ama sanki her servis ayrı ayrı yoruyor bizi” dedi. Cümle kısa, dert uzun. Aynı hafta İzmir’de bir SaaS startup’ta benzerini gördüm: MongoDB ile hızlı başlamışlar, sonra raporlama ve ilişki sorguları işin içine girince işler çorba olmuştu (yanlış duymadınız). Yani mesele teknoloji seçmek değil; doğru zamanda doğru bedeli ödemek.
Kısa bir not düşeyim buraya.
Mimari Kararlar Neden Bu Kadar Çabuk Eskiyor?
Açık konuşayım, Şimdi gelelim can alıcı noktaya. Yazılım mimarisi sabit bir anıt değil — ürün büyüyor, ekip değişiyor, müşteri beklentisi kayıyor, regülasyon geliyor, maliyet baskısı artıyor… Bir karar bugün çok mantıklı dururken yarın neden sorun çıkarıyor? Çünkü bağlam değişiyor. O kararı verdiğiniz günkü ölçek ile bugünkü ölçek aynı olmuyor, bu kadar basit aslında.
Aslında, Ben bunu ilk kez 2018’de Ankara’daki bir kurumsal projede net biçimde fark etmiştim (ki bu çoğu kişinin gözünden kaçıyor). Başlangıçta tek servisle çıkan sistem altı ay içinde dört ekibe bölündü, herkes “microservice yapalım” diye bastırdı — kağıt üstünde süperdi, pratikte ise log toplamak bile başlı başına iş oldu. Bir istek üç servisten geçerken hata ayıklamak bazen küçük bir dedektiflik oyununa dönüyordu, saatlerce. Evet. Saatlerce.
Bir dakika — bununla bitmedi.
Bu yüzden iyi mimari kararı demek “moda olanı seçmek” demek değil. İyi karar; bugünün ihtiyacını çözen ama yarının faturasıyla sizi boğmayan karardır. Bazen en olgun seçim geri adım atmaktır… kulağa ters geliyor ama gerçek hayatta çalışıyor.
Mimari kararların çoğu teknikten önce organizasyonel kararlardır: kaç kişi çalışıyor, ekipler nasıl bölünüyor, veri nerede duruyor ve hata olduğunda kim uyanacak?
1) Mikroservisleri Yanlış Ölçekte Kurmak
Mikroservislerin kötü olduğunu söylemek kolay olurdu —. Dürüst olayım, mesele mikroservisin kendisi değil, yanlış ölçekte kullanılması. Büyük organizasyonlarda gerçekten işe yarıyorlar; yüzlerce mühendisin olduğu yerde bağımsız dağıtım, takım özerkliği. Farklı teknolojileri aynı çatı altında yürütme kabiliyeti baya değerli oluyor, bunu inkâr etmek olmaz. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Gel gelelim küçük ekiplerde tablo farklılaşıyor. Beş-altı kişilik bir grupta on iki servise bölünmüş sistem gördüğümde içimden hep aynı şey geçiyor: “Bunu neden kendinize yaptınız?” Çünkü network çağrıları yüzünden gecikme artıyor, servisler arası bağımlılıklar büyüyor. Her deploy mini bir operasyon krizine dönüşüyor. Mini mi? Bazen değil. Daha fazla bilgi için Windows’ta Modern Standby Neden Kapatılır? Pil Gerçeği yazımıza bakabilirsiniz. Bu konuyla ilgili İki Taraflı Pazar Yeri Tasarımı: Göründüğünden Zor yazımıza da göz atmanızı tavsiye ederim.
Bir şey dikkatimi çekti: Bir de şu var: mikroservis çoğu zaman “ölçeklenebilirlik” diye pazarlanıyor ama gerçekte getirdiği ilk şey operasyon yükü oluyor — Docker konteynerleri tek başına masum görünüyor, ta ki gözlemleme katmanı kurana kadar (log, trace, metric üçlüsü, hepsini bir arada sağlıklı tutmak ayrı bir uzmanlık gerektiriyor). Orada eğlence bitiyor. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Kime göre iyi?
Vallahi, Eğer ekibiniz büyükse ve her takımın kendi teslim döngüsü varsa mikroservis mantıklı olabilir. Ama ürün erken aşamadaysa ya da trafik tahmin ettiğiniz kadar karmaşık değilse… açık konuşayım… fazladan mühendislik yapmış olursunuz. Bu kadar.
Kendi deneyimimden konuşuyorum, Bunu test ettiğim bir e-ticaret projesinde net gördüm; kampanya döneminde sorun yaşadığımız yer işlem hacmi değildi aslında, servisler arası sözleşmelerdi — sepet servisi tamam derken ödeme servisi başka şema bekliyordu — dürüst olayım, biraz hayal kırıklığı —. Bütün zincir ufak bir domino etkisine giriyordu, tam da en yoğun saatte. Daha fazla bilgi için John Deere uzlaşması: Tamir hakkı için büyük kırılma yazımıza bakabilirsiniz.
Neyi düzeltmeli?
- Sık konuşan servisleri tekrar değerlendirin.
- Sadece gerçekten bağımsız olması gereken parçaları ayırın.
- Kritik yol üzerindeki network çağrılarını azaltın.
- Önce domain sınırlarını netleştirin, sonra dağıtımı düşünün.
2) MongoDB’yi Her Şey İçin Kullanmak
Şunu fark ettim: NoSQL dalgasını hatırlıyorum da… herkes şemadan kaçıyordu sanki şema kötü bir alışkanlıkmış gibi! O dönem MongoDB gerçekten çok tatlıydı; hızlı prototipleme sağlıyor, geliştiriciye nefes aldırıyordu ve ürün tarafı sık sık alan değiştiriyorsa hayat kurtarıyordu. Haksız değildi bu tercih, o bağlamda.
Ama zaman geçince gerçek ortaya çıkıyor: veri modeli oturuyor, ilişkiler belirginleşiyor ve document yaklaşımı o kadar da esnek kalmıyor. Geçen yıl Berlin’de görüştüğüm bir B2B SaaS ekibinde bunu birebir gördüm — başta kullanıcı profilleri için ideal sanılan yapı, sonradan faturalama raporlarında kabusa dönüştü, çünkü ilişkisiz veri gibi görünen şeylerin hepsi birbirine dolanmaya başladı, özellikle audit kayıtlarında. Burada sorun MongoDB’nin kötü olması değil; yanlış iş için seçilmesi.
| Kriter | MongoDB | İlişkisel DB |
|---|---|---|
| Düşük başlangıç sürati | Evet | Evet ama daha disiplinli |
| Karmaşık join ihtiyacı | Zayıf kalabilir | Daha uygun |
| Schemanın sık değişmesi | Baya iyi gider | Daha fazla plan ister |
| Araştırma / raporlama / muhasebe yükü | Zorlaşır | Daha doğal akar |
Neyse uzatmayayım. Eğer sisteminiz artık olgunlaştıysa. Veriler arasındaki ilişkiler belirginleştiyse, sırf alışkanlık diye document modeline tutunmanın pek anlamı yok. Bazı ekipler hibrit modele geçerek rahatlıyor; ana işlemler için SQL tutup esnek içerik alanlarında NoSQL kullanıyorlar mesela — fena çalışan bir denge bu, gördüğüm kadarıyla.
3) Cache’i Mimarinin Merkezine Koymak
Bazı takımlar cache’i sihir gibi görüyor. Sorgu yavaş mı? Cache koyalım! Liste ekranı ağır mı? Cache! Kullanıcı şikâyet mi ediyor? Tabi yine cache… Sonra ne oluyor biliyor musunuz? Asıl problem çözülmeden üstüne halı serilmiş oluyor. Kalın bir halı.
Geçen sene Kadıköy’de birlikte çalıştığım bir medya girişimi vardı — onlarda Redis performansı toparladı ama veri tutarlılığı meselesini çözmedi, kısacası kullanıcıya hızlı yanlış bilgi göstermeye başladık. “Dur,” dedi proje yöneticisi o gün toplantıda, “önce neden bu kadar yavaş olduğumuzu anlayalım.” Haklıydı. Tartışmasız haklıydı.
Cache faydalıdır. Merkezî stratejiye dönüşünce tehlike başlıyor; eğer invalidation akışı oturmamışsa en güzel optimizasyon bile sizi yanıltabiliyor, üstelik fark etmesi de zaman alıyor.
Küçük startup’ta cache genelde güzel bir hızlandırıcıdır; özellikle okuma ağırlıklı sayfalarda fark yaratır. Enterprise seviyede ise durum başka — orada TTL politikaları, dağıtık kilitler, sıcak veri yönetimi derken iş büyür de büyür. Siz ne dersiniz? Bu yüzden cache’i önce yan araç olarak görmek lazım, temel yapı taşı olarak değil.
Ters giden yer neresi?
Sessiz problem genelde şurada çıkıyor: cache yüzünden gerçek veriyi test etmeyi unutuyorsunuz. Maalesef. Üstelik hata oluştuğunda uygulama yavaşlamak yerine yanlış cevap vermeye devam edebiliyor — bu, kullanıcı açısından çok daha sinir bozucu; çünkü en azından yavaşlıkta ne olduğunu hissediyorsunuz, yanlışlıkta ise güven gidiyor. O güveni geri kazanmak başka iş.
4) Gözlemleme Olmadan Büyüyen Sistem Kurmak
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
