Microservices vs Monolith: Pilihan Arsitektur yang Tepat untuk Startup Indonesia

Microservices vs Monolith: Pilih dengan Bijak

"We use microservices" terdengar keren di pitch deck. Tapi di balik layar, banyak startup yang menderita karena complexity yang tidak perlu.

Definisi Singkat

Monolith: Satu aplikasi, satu codebase, satu deployment unit. Semua fitur dalam satu service.

Microservices: Banyak service kecil yang independen, masing-masing handle satu domain bisnis, berkomunikasi via API atau message queue.

Realita Microservices yang Sering Tidak Diceritakan

Netflix, Uber, Amazon pakai microservices. Tapi mereka tidak mulai dari sana. Amazon.com awalnya monolith selama bertahun-tahun.

Complexity yang ditambahkan microservices:

• Network latency antar service
• Distributed tracing (debugging jauh lebih sulit)
• Data consistency antar database
• Service discovery dan load balancing
• Deployment orchestration (Kubernetes)
• Operational overhead yang jauh lebih tinggi

Kapan Monolith Adalah Pilihan Tepat?

Hampir selalu untuk:

• Startup tahap awal dan MVP
• Tim kurang dari 15 engineer
• Domain bisnis yang belum fully defined
• Ketika development speed adalah prioritas

Modular Monolith: Solusi Terbaik

Solusi terbaik untuk kebanyakan startup: modular monolith — satu deployment, tapi kode diorganisir seperti microservices di dalam.

app/
├── modules/
│   ├── auth/          # Modul autentikasi
│   │   ├── service.ts
│   │   ├── router.ts
│   │   └── types.ts
│   ├── orders/        # Modul pesanan
│   │   ├── service.ts
│   │   ├── router.ts
│   │   └── types.ts
│   ├── inventory/
│   └── notifications/
└── shared/
    ├── database.ts
    └── types.ts

Aturan antar modul:

• Modul tidak boleh import langsung dari modul lain
• Komunikasi hanya lewat interface yang didefinisikan
• Setiap modul punya tablespace sendiri di database

Kapan Mulai Pertimbangkan Microservices?

1. Tim besar — minimal 5+ engineer per service
2. Scaling requirement berbeda — payment service butuh 10x lebih banyak instance
3. Tech stack berbeda — ML service butuh Python, core app pakai Node.js
4. Reliability requirement berbeda — order service harus 99.99%, internal report bisa 99%

Communication Patterns

// Synchronous (REST) - untuk operasi yang butuh response segera
const user = await userServiceClient.getUser(userId)

// Asynchronous (Message Queue) - untuk operasi background
await messageQueue.publish("order.created", {
  orderId: order.id,
  userId: order.userId,
  total: order.total
})
// Notification service akan pick up dan kirim email/WA

Rekomendasi untuk Startup Indonesia 2026

Stage 0 (Idea/MVP):      Monolith sederhana di Vercel/Railway
Stage 1 (< 10k user):   Modular monolith, satu server
Stage 2 (10k-100k):     Monolith + beberapa async service
Stage 3 (100k+):        Microservices hanya untuk bottleneck

Jangan biarkan architecture astronaut syndrome menghambat Anda. Ship dulu, optimize kemudian.