Mimari sarkacı salındı
Varsayılan microservices dönemi bitti. Modular-monolith deseni kendini yeniden ortaya koydu ve 2026'da çoğu ekip aynı işi yapan beş microservice'ten iyi yapılandırılmış bir monolithle daha mutlu olur. Soru "monolith mi microservices mi" değil — "dağıtımın maliyeti ne zaman karşılığını vermeye başlar ve ikisinin en kötüsünden nasıl kaçınırım".Modular monolith — doğru varsayılan
Modular monolith, içsel olarak açık arayüzlerle ayrı modüller olarak düzenlenmiş tek deployable'dır. Desen:- Modüller birbirlerine dar API'lar (fonksiyonlar veya event'ler) sunar; modül sınırları arası doğrudan database erişimi yok.
- Her modül kendi tablolarını sahiplenir; yabancı modülün veriye ihtiyacı varsa API'dan gider.
- Build modül sınırlarını uygular — Maven multi-module, dotnet projeleri, Go'da paket sınırları vb.
- Bir deployable, bir süreç, bir database (veya paylaşılan altyapı içinde modül başına bir mantıksal database).
Elde ettiğiniz: düşük operasyonel yük, hızlı süreç içi çağrılar, basit transaction sınırları, basit deploy. Maliyeti olmadan microservices'in bakım faydalarının çoğu.
Yeterli olmadığı zaman
Modülü kendi servisine taşıyın:- Modülün gerisinden esaslı farklı ölçeklendirme karakteristikleri var (örneğin CRUD uygulaması içinde video transcoding).
- Modülün esaslı farklı güvenilirlik gereksinimleri var (örneğin çevreleyen admin tooling'den daha yüksek erişilebilirlik gerektiren ödeme işleme).
- Ekip sınırı kaydı — ayrı bir ekip bunu sahiplenecek ve deploy sıklığında özerklik istiyor.
- Teknoloji uyumsuzluğu gerçek — bir modül başka bir dil/runtime'da gerçekten daha iyi.
"Microservices best practice" için çıkarmayın. Şüpheci incelemeyi atlatan spesifik bir neden için çıkarın.
"Servis sınırı" sorusu
Bir servis sınırı aynı anda deploy sınırı, ekip sınırı ve veri sahiplik sınırıdır. Bunlardan herhangi birini yanlış yapın ve servis yerini aldığı modülden kötüdür.DDD tarzı heuristic: bounded contexts. Servis tutarlı bir alan sahiplenmeli — siparişler + sipariş kalemleri + sipariş yaşam döngüsü, "orders tablosu" değil. Servisler arası tablo paylaşımı bakım felaketine dönüşen bir kokudur.
Genellikle başarısız olan orta yol: distributed monolith
Distributed monolith, monolithi servislere böldüğünüzde ama senkron çağrı desenlerini ve paylaşılan database'leri tuttuğunuzda elde edersiniz. Dağıtımın operasyonel maliyetini ödersiniz ve eşleşmenin bakım maliyetini alırsınız. İkisinin de en kötüsü.Sahip olduğunuzun işaretleri:
- Bir servisteki değişiklik üçünün koordineli deploy'unu gerektirir.
- Servis A, servis B'nin database'inden doğrudan okur.
- Bir servisteki incident dakika içinde hepsine cascading geçer.
- Yerel geliştirme 8 servis çalıştırmayı gerektirir.
Burdaysanız, modular monolithe geri dönmek dağıtımı düzeltmekten ucuzdur.
Ölçekte hayatta kalan desenler
- Servisler arası iş akışı için async mesajlaşma (Kafka, NATS, RabbitMQ) — senkron zincirler hataları büyütür.
- Servisler arası transactionlar için saga deseni — XA / 2PC nadiren doğru cevap.
- Dış istemciler için API gateway / BFF deseni — dış tüketicilerin dahili servis topolojisini bilmesine izin vermeyin.
- Schema registry — servisler mesaj değişirken schema evolution kendi mühendislik yatırımıdır.
Uyaracağımız bir desen
v1 mimarisini v3 ölçeği için tasarlamak. "Ölçeğe hazır olmak için" 1. gün microservices gönderen ekip 18. ayda hâlâ traction almaya çalışıyordur. Sahip olduğunuz ekip ve yük için inşa edin. Gerçeklik talep ettiğinde yeniden mimarileyin.Mevcut mimariniz nedir? Migrasyoncular için — bir modülü çıkarmak vs monolitte tutmak arasında nasıl karar veriyorsunuz?
The architecture pendulum has swung
The microservices-by-default era is over. The modular-monolith pattern has reasserted itself, and most teams in 2026 are happier with a well-structured monolith than they would be with five microservices doing the same job. The question isn't "monolith or microservices" — it's "when does the cost of distribution start paying off, and how do I avoid the worst of both".The modular monolith — the right default
A modular monolith is a single deployable that's organised internally as separate modules with explicit interfaces. The pattern:- Modules expose narrow APIs (functions or events) to each other; no direct database access across module boundaries.
- Each module owns its tables; if a foreign module needs the data, it goes through the API.
- The build enforces module boundaries — Maven multi-module, dotnet projects, package boundaries in Go, etc.
- One deployable, one process, one database (or one logical database per module within shared infra).
What you get: low operational overhead, fast in-process calls, single transaction boundaries, simple deployment. Most of the maintainability benefits of microservices without the cost.
When it stops being enough
Move a module out to its own service when:- The module has materially different scaling characteristics from the rest (e.g. video transcoding inside a CRUD app).
- The module has materially different reliability requirements (e.g. payment processing needing higher availability than the surrounding admin tooling).
- The team boundary has shifted — a separate team is going to own this and they need autonomy on deploy cadence.
- The technology mismatch is real — one module is genuinely better in a different language / runtime.
Don't extract for "microservices best practice". Extract for a specific reason that survives a sceptical review.
The "service boundary" question
A service boundary is a deployment boundary, a team boundary, and a data ownership boundary all at once. Get any of these wrong and the service is worse than the module it replaced.The DDD-style heuristic: bounded contexts. A service should own a coherent domain — orders + order items + order lifecycle, not "the orders table". Sharing tables across services is a smell that becomes a maintenance disaster.
The middle ground that usually fails: distributed monolith
A distributed monolith is what you get when you split a monolith into services but keep the synchronous call patterns and shared databases. You pay the operational cost of distribution and get the maintenance cost of coupling. Worst of both.Signs you have one:
- A change to one service requires a coordinated deploy of three others.
- Service A reads from service B's database directly.
- An incident in one service cascades to all of them within a minute.
- Local development requires running 8 services.
If you're here, going back to a modular monolith is the cheaper option than fixing the distribution.
Patterns that survive at scale
- Async messaging (Kafka, NATS, RabbitMQ) for cross-service workflow — synchronous chains amplify failures.
- Saga pattern for cross-service transactions — XA / 2PC is rarely the right answer.
- API gateway / BFF pattern for external clients — don't let external consumers know the internal service topology.
- Schema registry — when services exchange messages, schema evolution is its own engineering investment.
One pattern we'd warn about
Designing the v1 architecture for the v3 scale. The team that ships microservices on day 1 to "be ready for scale" is usually still struggling to get traction at month 18. Build for the team and the load you have. Re-architect when reality demands it.What's your current architecture? And — for the migration folks — how do you decide when to break a module out vs leave it in the monolith?
