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 sızı rahat ettiriyor, bazıları işe 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.
Mimarı 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 işe 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 mimarı kararı demek “moda olanı seçmek” demek değil. İyi karar; bugünün ihtiyacını çözen ama yarının faturasıyla sızı boğmayan karardır. Bazen en olgun seçim geri adım atmaktır… kulağa ters geliyor ama gerçek hayatta çalışıyor.
Mimarı 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 takimin 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 kâbusa 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’nın 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 Mimarının 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 müsünüz? 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. “Dür,” 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 sızı yaniltabiliyor, ü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 işe 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 sınır bozucu; çünkü en azından yavaşlıkta ne olduğunu hissediyorsunuz, yanlışlıkta işe güven gidiyor. O güveni geri kazanmak başka iş.
4) Gözlemleme Olmadan Büyüyen Sistem Kurmak
Sıkça Sorulan Sorular
Mikroservisler neden bazen “yoruyor” ve teknik borç artırıyor?
Mikroservis mimarisi tek başına kötü değil; sorun genelde yanlış ölçek ve yanlış operasyon modelinde çıkıyor. Servis sayısı arttıkça dağıtık izleme, log korelasyonu, hata ayıklama ve CI/CD karmaşıklığı da artıyor. Ben küçük ekiplere mikroservisi erken dönemde dayatınca, “çalışıyor” ile “sürdürülebilir” arasının hızla açıldığını sık gördüm.
İyi karar, bugünün ihtiyacını çözerken yarının maliyetini de kontrol altında tutan karardır. Yani “en yeni yaklaşım” değil; ekip yapısı, teslim hızı, veri modeli ve operasyon kapasitesiyle uyumlu olan seçim önem kazanır. Benim pratikte en işe yarayan yaklaşım, kararı verirken geri dönüş maliyetini (rollback/replace) açıkça tartmak oldu.
En sık gördüğümüz işaretler: raporlama için aşırı karmaşık sorgular, birden fazla servisin aynı veriyi “tutarsız” şekilde güncellemesi ve performans sorunlarının zamanla büyümesi. Ayrıca istek akışı bir servisten diğerine geçtikçe hata ayıklama süresi uzar. “İlişkisel sorgu” ihtiyacı arttıkça tasarımın yeniden düşünülmesi gerektiği de sık yaşanır.
Çünkü bağlam değişiyor: kullanıcı sayısı, ölçek, ekip kompozisyonu, regülasyonlar ve maliyet baskısı aynı kalmıyor. Bugün mantıklı gelen bir varsayım, birkaç ay sonra operasyon yükü ya da bakım maliyeti olarak geri dönebiliyor. Bu yüzden mimarinin “taş gibi” değil, yönetişimi olan bir sistem gibi ele alınması gerekiyor.
Bazen en olgun hamle, gereksiz karmaşıklığı azaltmak ve sınırları yeniden çizmek oluyor. Örneğin servis sayısını azaltmak, modüler monolit yaklaşımına dönmek veya veri sorumluluklarını netleştirmek teknik borcu hızla düşürebilir. Benzer bir senaryoda, önce izleme/operasyon olgunlaşmadan dağıtık mimariye geçmenin geri dönüş maliyetini büyüttüğünü görmüştüm.
Kaynaklar ve İleri Okuma
Azure Architecture Center (Guides & Patterns)
Microservices Architecture (Microsoft Learn)
Azure Data Architecture Guide (Microsoft Learn)
OpenTelemetry Specification (Dağıtık İzleme Standardı)
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.
