Belajar System Design - Microservices Architecture

#Pendahuluan

Setelah di episode 14 kita memahami fault tolerance dan resilience patterns, pada episode ini kita masuk ke arsitektur yang paling sering dibahas dan disalahartikan: microservices. Microservices bukan solusi untuk semua masalah — ia adalah trade-off antara independensi deployment dan operational complexity. Banyak organisasi yang terlalu cepat mengadopsi microservices dan akhirnya terjebak dalam distributed monolith yang lebih buruk dari monolith asli.

Di episode ini kita bedah microservices secara jujur: kapan ia tepat, kapan tidak, dan bagaimana melakukannya dengan benar. Di episode 17 kita akan membahas migrasi dari monolith ke microservices — karena kebanyakan sistem dimulai dari monolith.

#Service Boundary

#By Business Capability

Business capability adalah "apa yang bisnis lakukan" — bukan "apa yang sistem lakukan."

Business Capability	Service	Tanggung Jawab
Manajemen Pengguna	User Service	Registration, profile, auth
Manajemen Produk	Product Service	Catalog, inventory, pricing
Pemrosesan Order	Order Service	Cart, checkout, order status
Pembayaran	Payment Service	Payment processing, refund
Notifikasi	Notification Service	Email, push, SMS

#Prinsip Service Boundary

Loose coupling: perubahan di satu service tidak memerlukan perubahan di service lain.
High cohesion: terkait logika berada dalam satu service.
Single responsibility: satu service, satu tanggung jawab.
Data ownership: setiap service punya database sendiri — jangan share database!

#Komunikasi Antar Service

#Synchronous (REST/gRPC)

100%

Kapan pakai: query yang membutuhkan response langsung (get product detail, check availability).

#Asynchronous (Queue/Event)

100%

Kapan pakai: operasi yang bisa ditunda (send email, update analytics, process payment async).

#Service Mesh

Service mesh (Istio, Linkerd) mengelola komunikasi antar service di level infrastruktur.

Fitur	Penjelasan
Traffic management	Load balancing, routing, circuit breaking
Security	mTLS antar service, authorization policy
Observability	Distributed tracing, metrics, logging
Resilience	Retry, timeout, rate limiting

Service mesh architecture

Service A → Sidecar Proxy (Envoy) → Network → Sidecar Proxy → Service B
 
Semua traffic melalui sidecar proxy → proxy handle:
- mTLS encryption
- Circuit breaking
- Load balancing
- Distributed tracing

#Trade-off Microservices

#Kelebihan

Independent deployment: deploy satu service tanpa deploy yang lain.
Technology diversity: setiap service bisa pakai bahasa/framework berbeda.
Scalability: scale hanya service yang sibuk.
Fault isolation: service yang crash tidak mengambil semua sistem.

#Kekurangan

Distributed complexity: debugging sulit, latency network, data consistency.
Operational overhead: lebih banyak yang harus dimonitor, di-deploy, di-maintain.
Network dependency: semua komunikasi lewat network (bukan in-process).
Data management: setiap service punya database sendiri → no JOIN lintas service.

#"Don't Start with Microservices"

Monolith → Microservices decision tree

Startup kecil (<10 engineer)?
  → Monolith (fokus build product, bukan infra)
 
Tim sudah besar (>20 engineer)?
  → Pertimbangkan split ke microservices untuk independensi
 
Satu service sering crash mempengaruhi semua?
  → Pecah service yang bermasalah
 
Deployment tetap butuh coordination semua tim?
  → Pecah untuk independent deploy

Warning

Microservices bukan starting point yang tepat untuk kebanyakan startup. Mulai dari monolith yang terstruktur (modular monolith), lalu pecah ke microservices saat ada kebutuhan nyata. "Don't start with microservices" adalah wisdom yang terbukti di ribuan organisasi.

#Praktik: Monolith → Microservices Boundaries

#Identifikasi Service Boundaries

E-commerce service boundaries

Monolith (satu codebase):
├── users/
├── products/
├── orders/
├── payments/
└── notifications/
 
Microservices (setiap folder jadi service):
├── user-service (PostgreSQL, REST API)
├── product-service (PostgreSQL, gRPC)
├── order-service (PostgreSQL, REST + events)
├── payment-service (PostgreSQL, gRPC)
└── notification-service (Redis, event-driven)

#Communication Pattern

Communication pattern per service pair

User Service ↔ Product Service: REST (query user data)
Order Service → Payment Service: gRPC (create payment)
Order Service → Notification Service: Event (order created)
Payment Service → Order Service: Event (payment processed)

#Penutup

Inti yang harus dibawa pulang:

Service boundary by business capability — loose coupling, high cohesion, data ownership per service.
Sync (REST/gRPC) untuk query langsung; async (queue/event) untuk operasi yang bisa ditunda.
Service mesh (Istio/Linkerd) mengelola traffic, security, dan observability di level infrastruktur.
Trade-off: independensi deployment vs distributed complexity — jangan mulai dengan microservices tanpa kebutuhan nyata.

Di episode 16 selanjutnya kita akan membahas event-driven architecture & CQRS — event emitter, event broker (Kafka), choreography vs orchestration (saga pattern), CQRS (command query responsibility segregation), dan outbox pattern untuk reliable event publishing. Event-driven adalah pola komunikasi yang powerful untuk microservices!