Microservices #

Microservices adalah gaya arsitektur software di mana sebuah sistem besar dipecah menjadi sekumpulan service kecil yang independen, loosely coupled, dan berfokus pada satu tanggung jawab bisnis (single responsibility per service).

Berbeda dengan monolith, microservices memungkinkan setiap service:

Dikembangkan oleh tim berbeda
Dideploy secara independen
Diskalakan sesuai kebutuhan masing-masing
Menggunakan teknologi yang berbeda (polyglot)

Namun, microservices bukan solusi default. Ia membawa kompleksitas baru yang harus dipahami sejak awal.

Gambaran Besar Arsitektur Microservices #

Berikut adalah gambaran besar (high-level) arsitektur microservices yang umum ditemui di production system:

                +------------------+
                |   Client / UI    |
                | (Web / Mobile)   |
                +--------+---------+
                         |
                         v
                +------------------+
                |   API Gateway    |
                | Auth, RateLimit, |
                | Routing, TLS     |
                +---+----+----+----+
                    |    |    |
        -------------    |    -------------
        v                  v                  v
+---------------+  +---------------+  +---------------+
| User Service  |  | Order Service |  | Payment Svc   |
| (Auth, User)  |  | (Order Flow)  |  | (Billing)    |
+-------+-------+  +-------+-------+  +-------+-------+
        |                  |                  |
        v                  v                  v
+---------------+  +---------------+  +---------------+
| User DB       |  | Order DB      |  | Payment DB   |
| (Private)     |  | (Private)     |  | (Private)   |
+---------------+  +---------------+  +---------------+

        async events / message broker (Kafka / PubSub / SQS)

Prinsip penting dari diagram di atas: #

API Gateway sebagai single entry point
Setiap service memiliki database sendiri (no shared DB)
Komunikasi bisa sync (HTTP/gRPC) atau async (event/message)
Service tidak saling tahu detail internal service lain

Karakteristik Utama Microservices #

1. Independently Deployable #

Setiap service bisa dideploy tanpa harus redeploy service lain.

Contoh:

Bug di payment-service → deploy ulang payment saja
Tidak perlu redeploy user-service

2. Single Responsibility per Service #

Satu service fokus ke satu domain bisnis.

Contoh:

user-service → autentikasi & profil user
order-service → lifecycle order
inventory-service → stok barang

🚫 Anti-pattern:

Satu service meng-handle user + order + payment

3. Decentralized Data Management #

Setiap service memiliki data dan schema sendiri.

user-service  → user_db
order-service → order_db
payment       → payment_db

Manfaat:

Tidak ada tight coupling lewat database
Skema bisa berubah tanpa merusak service lain

Konsekuensi:

Tidak bisa join data lintas service
Harus siap dengan eventual consistency

4. Communication Over Network #

Komunikasi antar service terjadi lewat network:

REST / HTTP
gRPC
Message broker (event-driven)

Implikasi:

Network latency
Partial failure
Timeout & retry menjadi wajib

Pola Komunikasi Microservices #

1. Synchronous (Request–Response) #

Service A ──HTTP/gRPC──> Service B

Kapan dipakai:

Read data
Flow sederhana

Risiko:

Cascading failure
Tight runtime dependency

2. Asynchronous (Event-Driven) #

Service A ──Event──> Broker ──> Service B

Kapan dipakai:

Proses panjang
Integrasi lintas domain
High throughput

Manfaat:

Lebih resilient
Lebih scalable

Best Practices Microservices #

1. Jangan Mulai dari Microservice #

❗ Microservices adalah evolusi, bukan starting point.

Best practice:

Mulai dari monolith yang rapi (modular monolith)
Pecah jadi microservices saat:
- Tim membesar
- Deployment jadi bottleneck
- Scaling requirement berbeda-beda

2. Gunakan API Gateway #

Fungsi utama API Gateway:

Authentication & Authorization
Rate limiting
Request routing
TLS termination

🚫 Jangan taruh logic bisnis di gateway.

3. Database per Service (Wajib) #

Aturan keras:

No shared database

Jika butuh data service lain:

Panggil API-nya
Subscribe event-nya

4. Observability Sejak Hari Pertama #

Microservices tanpa observability = mimpi buruk.

Wajib ada:

Centralized logging
Metrics (latency, error rate, throughput)
Distributed tracing (trace-id)

5. Resilience Pattern #

Karena failure adalah keniscayaan:

Timeout
Retry dengan backoff
Circuit breaker
Bulkhead

Client → Gateway → Service
           |
        Circuit Breaker

6. Contract & Versioning API #

Perubahan API harus backward-compatible.

Praktik umum:

/v1, /v2
Schema validation
Consumer-driven contract test

7. Automasi Deployment #

Microservices tidak mungkin di-manage manual.

Best practice:

CI/CD pipeline per service
Infrastructure as Code
Blue-green / Canary deployment

Microservices vs Service-Based Architecture (SBA) #

Apa itu Service-Based Architecture (SBA)? #

Service-Based Architecture adalah arsitektur di mana aplikasi:

Sudah dipisah menjadi beberapa service
Biasanya masih dalam satu bounded system / satu domain besar
Jumlah service relatif sedikit (3–10 service)
Deployment dan data belum sepenuhnya independen

SBA sering muncul sebagai:

Evolusi dari monolith
Bentuk modular monolith yang dipisah secara fisik
Tahap transisi sebelum microservices

Perbandingan Service-Based Architecture vs Microservices #

Aspek	Service-Based Architecture	Microservices
Tujuan utama	Struktur & maintainability	Scalability & autonomy
Jumlah service	Sedikit (coarse-grained)	Banyak (fine-grained)
Domain boundary	Satu domain besar	Banyak bounded context
Deployment	Sering masih bareng	Independen per service
Database	Sering masih shared	Database per service
Coupling	Medium	Loose coupling
Operasional	Relatif sederhana	Kompleks

Gambaran Arsitektur #

Service-Based Architecture #

Client
  |
  v
+-----------+
| API Layer |
+-----------+
   |    |
   v    v
+------+  +------+
| User |  | Order|
| Svc  |  | Svc  |
+------+  +------+
      \____/
     shared database

Microservices #

Client
  |
  v
API Gateway
  |
  v
+------+   +------+   +---------+
| User |   | Order|   | Payment |
| Svc  |   | Svc  |   | Svc     |
+------+   +------+   +---------+
  |          |            |
 user_db   order_db    payment_db

Kapan Service-Based Architecture Sudah Cukup? #

SBA sudah sangat memadai jika:

Tim masih kecil–menengah
Domain bisnis belum terlalu kompleks
Scaling masih bisa dilakukan bersama
Fokus utama adalah maintainability

Dalam banyak kasus:

Service-Based Architecture adalah sweet spot antara monolith dan microservices.

Kapan SBA Menjadi Masalah? #

SBA mulai terasa sakit ketika:

Satu service butuh scale ekstrem
Deployment satu service sering mengganggu service lain
Ownership antar tim mulai kabur
Release cycle makin lambat

Di titik ini, barulah microservices layak dipertimbangkan.

Best Practice Evolusi SBA → Microservices #

Pastikan SBA sudah rapi (clean boundary)
Identifikasi domain dengan scaling tertinggi
Pisahkan data ownership lebih dulu
Perkenalkan event-driven communication
Jangan pecah semuanya sekaligus

Kapan Microservices Cocok? #

Apakah tim kecil (<5)? ── Ya ──> Monolith
           |
           Tidak
           v
Butuh scaling berbeda per domain?
           |
           Ya
           v
Deployment sering saling ganggu?
           |
           Ya
           v
      Microservices

Kesalahan Umum (Anti-Patterns) #

Shared database antar service
Chatty synchronous calls
Distributed monolith
Terlalu banyak service kecil tanpa kebutuhan nyata

Penutup #

Microservices menawarkan fleksibilitas, scalability, dan autonomy, tetapi dibayar dengan kompleksitas operasional.

Kunci sukses microservices bukan di teknologinya, tetapi di:

Boundary domain yang jelas
Automasi
Observability
Disiplin engineering

Jika fondasi ini belum siap, microservices justru akan menjadi beban, bukan solusi.