Bir startup’ta mimari tartışması vardı. CTO “her endpoint ayrı microservice olsun” diyordu. Takımda dört developer’dık ve hesaplara göre 40 microservice kuracaktık. Dört kişi, kırk servis. O toplantıda ilk defa yüksek sesle “bu delilik” dedim. Microservice granularity konusunda pratik öğrendiklerimi paylaşayım.
Çok küçük tuzağı (nano-services)
Her bir tekil fonksiyon için ayrı servis. “Email doğrulama servisi”, “şifre hash servisi”, “telefon format servisi”. Her biri ayrı deploy, ayrı repo, ayrı test, ayrı monitoring.
Sorunlar:
– Network call’lar patlar. Bir request 10 servis dolaşır, latency toplanır.
– Distributed tracing zorunluluk hale gelir, debug karmaşıklaşır.
– Takımın büyük kısmı servisler arası iletişim kodu yazıyor, asıl iş yazmıyor.
– Deploy koordinasyonu imkansız. Versiyonlu API şart oluyor, breaking change etrafından dolaşıyorsunuz.
– Ortak kod tekrar ediyor veya shared library oluyor, shared library değişince birçok servis etkileniyor.
Çok büyük tuzağı (monolith-ish microservice)
Bir servis 10 farklı domain’i kapsıyor. “User service” içinde auth, profile, billing, notification preferences, avatar upload hepsi var. 30 endpoint, 15 tablo.
Sorunlar:
– Deploy ederken her değişiklik büyük alanı etkiliyor.
– Farklı takımlar aynı servise PR açıyor, çakışma çok.
– Ölçekleme granular değil. Sadece billing trafiği artınca tüm servisi büyütmek zorunda kalıyorsunuz.
– Test süresi uzuyor, CI yavaşlıyor.
Doğru granularity kriterleri
Tek altın kural yok. Kullandığım kriterler:
- Bounded context (DDD). Servisler domain sınırlarına göre bölünmeli. Authentication, billing, inventory, notification. Her birinin kendi domain dili var. Bir domain içinde birleşik kalmak daha güvenli.
- Takım sahipliği. Bir servisi iki takım yönetiyorsa zaten yanlış. “You build it, you run it” prensibi. Servis sayısı takım sayısından fazla olabilir ama takım başına 3-5 servis’i aşmamalı.
- Deploy frekansı. Aynı sıklıkta deploy edilen parçalar aynı serviste kalabilir. Payment flow haftada bir deploy ediliyor, notification flow her gün. Bunları ayırmak mantıklı.
- Failure domain. Bir kısmın hata vermesi diğerini etkilememeli. Checkout servisi çökerse search çalışmaya devam edebilsin.
- Ölçekleme ihtiyacı farklı mı? Image processing CPU-heavy, normal API I/O-heavy. Ayrı ayrı ölçeklemek için ayrı servis.
Pratik örnek: e-ticaret
Benim ölçek tavsiyem 8-12 microservice, 10-15 kişilik takım için:
- Auth (login, registration, token, password reset)
- User (profile, preferences, address book)
- Catalog (product, category, search index)
- Inventory (stock, warehouse, availability)
- Cart (basket state)
- Checkout (order creation, payment orchestration)
- Payment (gateway integration, refund)
- Fulfillment (shipment, tracking)
- Notification (email, SMS, push)
- Review (ratings, comments)
- Recommendation (personalization)
- Analytics (events, reporting)
Her biri ayrı takım sahibi değilse bile tematik olarak ayrık. Auth ve User ayrı gibi görünüyor ama çoğu zaman aynı takım yönetiyor, iki ayrı servis’in maliyeti karşılığında uzun vadede bağımsız ölçekleme faydası veriyor.
“Modüler monolith” alternatifi
Dikkat, microservice her projenin ilk adımı olmamalı. Çoğu startup için modüler monolith daha uygun. Kodu domain’lere göre ayırın ama tek deployment olarak tutun. Büyüdükçe hangi modül kendi servisi olacak karar verirsiniz.
Şu noktalarda ayrılma sinyalleri çıkıyor:
- Bir modül diğerlerinden çok farklı hızlarda ölçekleniyor.
- Bir modül farklı teknoloji gerektiriyor (Python ML vs Node.js web).
- Takım büyüdü, bir modülün tek sahibi olan alt takım oluştu.
- Deploy döngüleri çakışmaya başladı.
Migration stratejisi
Monolith’ten microservice’e strangler fig pattern ile geçiş iyi çalışıyor. Yeni feature’lar microservice olarak doğuyor, mevcut modüller zamanla ayrılıyor. Big bang rewrite çoğu zaman başarısız.
Ölçüm: servis başına ne düşüyor?
Her microservice bir maliyet taşıyor:
- Repo, CI/CD pipeline
- Monitoring, logging, alerting
- Deployment, rollback
- Dokümantasyon
- Runbook
- On-call
- Inter-service authentication
Bir servisin yıllık operasyonel maliyeti (developer zamanı + infra) 15-25 bin dolar civarı gözüme geldi. Faydası bu maliyeti karşılamıyorsa ayrı servis değil.
Conway’s Law
Mimari, organizasyonun iletişim yapısını yansıtır. Takım organizasyonunuz ne şekildeyse servisler de benzer şekilde oluşur. Servis çizimi yaparken “bu takım bunu sahiplenebilir mi?” sorusu önemlidir.
Sonuç
Microservice bir araç, mimari din değil. Her projede granularity farklı doğru cevaba sahip. Takımı, iş gereksinimlerini, ölçek ihtiyacını birlikte değerlendirin. “Küçük olsun” veya “büyük olsun” diye peşin yargılar yerine bağlam bazlı karar verin.