# Yeni bir projeye mikroservislerle mi başlamalıyım?

> Sıfırdan başlayan çoğu üründe modüler monolitle başlayıp sınırları kodda zorlayın; bir modülü ancak ayrı ölçeklenmesi gerektiğinde servise terfi ettirin.

- Soruldu: 2026-05-20
- Yanıtlandı: 2026-05-22
- Soran: Emre
- Etiketler: mimari, mikroservis
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/yeni-projeye-mikroservisle-mi-baslamali/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Yeni bir ürün geliştirmeye başlıyorum ve henüz küçük bir ekibiz. Mimariyi en baştan mikroservislerle kurmayı düşünüyorum — ileride ölçeklenmem gerektiğinde sancı yaşamamak için işe baştan "doğru" şekilde başlamak mantıklı geliyor. Ama bu kadar erken bir aşamada mikroservislerin getireceği karmaşıklığa değer mi, yoksa monolitle mi başlamalıyım? Sıfırdan bir projede senin önerin ne olurdu?


Kısa cevap: Büyük ihtimalle hayır. Sıfırdan başlayan çoğu ürün için doğru başlangıç noktası, **iyi modüllere ayrılmış bir monolit**tir.

## Kısa cevap

Mikroservislerin çözdüğü asıl problem teknik değil, **organizasyoneldir**: birbirinden bağımsız deploy edilebilen, ayrı ekiplerin sahiplendiği, farklı hızlarda ölçeklenmesi gereken parçalar. Tek kişilik ya da küçük bir ekipseniz ve domain'i henüz tam oturmadıysa, bu problemlerin hiçbirine sahip değilsiniz.

## Neden

1. **Bedeli baştan ödüyorsunuz, faydayı sonra alıyorsunuz.** Ağ gecikmesi, kısmi hatalar, dağıtık transaction, gözlemlenebilirlik ve deploy karmaşası ilk günden faturalanır; ayrı ölçeklenme ihtiyacı ise aylar sonra — belki de hiç — gelir.

2. **Domain oturmadan çizilen sınır yanlış çizilir.** Ürünün ne olduğunu henüz öğreniyorken servis sınırı koymak, o sınırı ağ üzerinden betona dökmek demektir.

3. **Yanlış servis sınırını düzeltmek, monolitten çıkmaktan zordur.** "Monolitten servise çıkmak zor" derler; doğrudur — ama iyi çizilmiş sınırların olduğu bir monolitten çıkmak, baştan yanlış çizilmiş servis sınırlarını düzeltmekten çok daha kolaydır.

## Ne yapmalı

1. **Modüler monolitle başlayın.** Domain'i net sınırlara (bounded context) bölün, ama hepsini tek bir deploy edilebilir uygulamada tutun. Modüller arası iletişimi açık arayüzlerden geçirin, doğrudan tabloya uzanmayın.

2. **Sınırları kodda zorlayın.** Modüller arasında dairesel bağımlılığa izin vermeyin. Bu disiplin, ileride bir modülü servise çıkarmanız gerektiğinde işin büyük kısmını önceden yapmış olmanızı sağlar.

3. **Acıyı ölçtüğünde ayırın.** Bir modül gerçekten ayrı ölçeklenmek zorunda kaldığında, ayrı bir ekip onu sahiplendiğinde ya da deploy'lar birbirini bloke etmeye başladığında — işte o zaman o sınırı bir servise terfi ettirin. O günün nasıl yürütüleceğini [ödeme modülünü Strangler Fig ile koparma kaydında](/sor-bakalim/monolitten-mikroservise-strangler-fig-ile-kademeli-gecis/) adım adım anlattım.

**Sonuç:** Mikroservis bir hedef değil, belirli bir ölçekte ödediğiniz bir **bedeldir**; o ölçeğe ulaşmadan ödemeye başlamayın. Ben olsam modüler monolitle başlar, sınırları kodda zorlar ve bir modülü ancak ölçülmüş bir acı ortaya çıktığında servise terfi ettirirdim. Mimari muhakemenin tamamını sade.dev'de açıyorum.

## İlgili Yazılar

- [Projelere Neden Modüler Monolit ile Başlıyorum?](https://sade.dev/tr/journal/projelere-neden-moduler-monolit-ile-basliyorum) — sade.dev
- [Mikroservise Ne Zaman Geçerim?](https://sade.dev/tr/journal/mikroservise-ne-zaman-gecerim) — sade.dev
- [PHP monolitten ödeme modülünü Strangler Fig ile nasıl koparırım?](https://www.muhammetsafak.com.tr/sor-bakalim/monolitten-mikroservise-strangler-fig-ile-kademeli-gecis/) — Sor Bakalım
- [Mikroservislerde dağıtık izlemeyi (OpenTelemetry) nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/mikroserviste-dagitik-izleme-opentelemetry-ile-nasil-kurulur/) — Sor Bakalım
- [Laravel ve Go servisleri arasında mesaj şeması için Protobuf mu, JSON Schema mı?](https://www.muhammetsafak.com.tr/sor-bakalim/laravel-ve-go-arasinda-mesaj-semasi-protobuf-mu-json-schema-mi/) — Sor Bakalım