Belajar System Design - Migrasi: Monolith ke Modular Monolith ke Microservices

#Pendahuluan

Setelah di episode 16 kita memahami event-driven architecture dan CQRS, pada episode ini kita membahas topik yang sangat relevan di 2026: bagaimana bermigrasi dari monolith ke arsitektur yang lebih scalable? Jawabannya bukan "langsung ke microservices" — tapi perjalanan bertahap yang dimulai dari modular monolith.

Trend 2026 menunjukkan "microservices hangover" — banyak organisasi yang terlalu cepat ke microservices dan mengalami operational complexity yang berlebihan. Shopify, Stack Overflow, dan GitHub membuktikan bahwa modular monolith yang terstruktur bisa menangani scale ratusan juta pengguna.

#Strangler Fig Pattern

#Konsep

Strangler Fig adalah pola migrasi di mana modul baru dibangun sebagai microservice, sementara modul lama tetap di monolith — secara bertahap "menjepit" monolith sampai tidak ada yang tersisa.

Strangler Fig migration

Phase 1: Monolith (100% traffic)
  ├── User module
  ├── Product module
  ├── Order module
  └── Payment module
 
Phase 2: User extracted ke microservice
  ├── User Service (new) ← 100% user traffic
  ├── Product module (di monolith)
  ├── Order module (di monolith)
  └── Payment module (di monolith)
 
Phase 3: Product extracted
  ├── User Service
  ├── Product Service (new)
  ├── Order module (di monolith)
  └── Payment module (di monolith)
 
... dst sampai semua modul ter-extract

#Prinsip Migrasi

Jangan rewrite dari nol — migrasi bertahap, bukan big bang.
Router menentukan — API gateway/router menentukan traffic ke monolith atau service baru.
Data migration terpisah — pindahkan data per modul, jangan sekaligus.
Test secara gradual — production traffic perlahan dialihkan.

#Modular Monolith

#Konsep

Modular monolith adalah monolith yang di-structure dengan module boundaries yang jelas — seperti microservices tapi dalam satu deployment.

Modular monolith structure

src/
├── modules/
│   ├── user/
│   │   ├── api/          # Public API (interface)
│   │   ├── internal/     # Implementation detail
│   │   ├── model/        # Domain models
│   │   └── repository/   # Data access
│   ├── product/
│   │   ├── api/
│   │   ├── internal/
│   │   ├── model/
│   │   └── repository/
│   ├── order/
│   │   ├── api/
│   │   ├── internal/
│   │   ├── model/
│   │   └── repository/
│   └── payment/
│       ├── api/
│       ├── internal/
│       ├── model/
│       └── repository/
├── shared/              # Shared utilities (no business logic)
└── app.ts              # Entry point, register modules

#Package-by-Feature

Package-by-feature (modular monolith)

✅ GOOD: modules/user/, modules/product/, modules/order/
   → Setiap module punya public API dan internal implementation
 
❌ BAD: controllers/, models/, services/, repositories/
   → Berdasarkan teknologi, bukan business capability
   → Memaksa cross-module dependencies

#Public API vs Internal

Module boundary enforcement

modules/user/api/index.ts  → Public API (export)
modules/user/internal/     → Internal (tidak bisa diakses dari luar module)
modules/user/model/        → Domain models (bisa di-share via API)

Rule: modul hanya boleh akses modul lain lewat public API — tidak boleh import internal.

#Data Isolation

Data isolation dalam modular monolith

Setiap module punya schema sendiri:
- Schema: user_schema, product_schema, order_schema
- atau: shared database tapi tabel per module
- atau: database per module (mirip microservices)
 
Public API untuk akses data:
- Order module tidak boleh query tabel user langsung
- Harus lewat UserService.getUser(userId)

#Modular Monolith vs Microservices

Aspek	Modular Monolith	Microservices
Deployment	Satu deployment	Deploy per service
Latency	In-process (very fast)	Network (ms overhead)
Data	Shared database (schema isolation)	Database per service
Scalability	Vertical + horizontal (load balancer)	Horizontal per service
Complexity	Rendah (satu codebase)	Tinggi (banyak service)
Technology	Satu stack	Polyglot
Team size	Cocok untuk 5-50 engineer	Cocok untuk 50+ engineer

#Kapan Extract ke Microservices

Extract dari modular monolith ke microservices ketika:

Tim terlalu besar — modul yang sama sering di-deploy oleh berbeda tim → bottleneck.
Scale requirement berbeda — satu modul butuh 10x scale dari yang lain.
Technology requirement berbeda — satu modul butuh ML inference (Python), yang lain Go.
Deployment frequency tinggi — satu modul di-deploy 10x/hari, yang lain 1x/minggu.

Tip

Modular monolith adalah recommended starting point untuk 2026. Shopify (ratusan juta pengguna), Stack Overflow, dan GitHub membuktikan bahwa monolith yang terstruktur bisa menangani scale besar. Mulai dari sini, extract ke microservices saat ada kebutuhan nyata.

#Praktik: Migrasi Step-by-Step

#Step 1: Struktur Modular Monolith

Phase 1: Modular monolith

Monolith dengan module boundaries:
- modules/user/
- modules/product/
- modules/order/
- modules/payment/
 
Public API interface per module
Schema isolation di database

#Step 2: Extract Payment Service

Phase 2: Extract payment

Payment module → Payment Service (microservice)
- Payment Service punya database sendiri
- Order Service komunikasi ke Payment via gRPC
- Event: OrderCreated → Payment Worker → PaymentProcessed

#Step 3: Extract Notification Service

Phase 3: Extract notification

Notification module → Notification Service
- Event-driven: listen ke semua event
- Database sendiri untuk template dan delivery log
- Independen dari modul lain

#Step 4: Evaluate

Evaluate extraction

Setiap extraction tanyakan:
- Apakah ini menyelesaikan masalah nyata?
- Apakah operational complexity worth it?
- Apakah tim bisa manage service baru ini?
Jika tidak → tetap di modular monolith.

#Penutup

Inti yang harus dibawa pulang:

Strangler Fig = migrasi bertahap: modul baru di microservice, lama di monolith.
Modular monolith = monolith dengan module boundaries jelas — package-by-feature, public API, data isolation.
Recommended starting point 2026: Shopify, Stack Overflow, GitHub membuktikan scale besar.
Extract ke microservices saat ada kebutuhan nyata: tim besar, scale berbeda, technology berbeda, deployment frequency tinggi.

Di episode 18 selanjutnya kita akan membahas serverless & edge architecture — Lambda/Cloud Run/Cloudflare Workers, cold start, edge computing, dan perbandingan cost/latency antara container, Lambda, dan edge worker. Serverless mengubah cara kita berpikir tentang deployment dan scaling!