Saya pernah advise sebuah startup untuk migrate dari monolith ke microservices. Enam bulan kemudian mereka kembali ke monolith — bukan karena teknologinya salah, tapi karena tim mereka tidak berubah.
Conway's Law menyatakan bahwa sistem yang dibangun organisasi akan mencerminkan struktur komunikasi organisasi tersebut. Ini bukan observasi — ini hukum yang hampir tidak bisa dilawan.
Conway's Law — Apa Artinya dalam Praktik
Implikasinya konkret: kalau tim Anda terdiri dari 3 orang yang semuanya ngobrol langsung setiap hari, sistem yang Anda bangun akan natural menuju 1 atau 2 komponen besar yang saling terhubung erat — bukan 12 microservices independen.
Anti-Pattern: Distributed Monolith
Ini yang terjadi pada startup yang saya ceritakan di awal: mereka memecah kode menjadi microservices, tapi tim masih sama dan saling bergantung. Hasilnya bukan microservices — ini distributed monolith.
| Karakteristik | True Microservices | Distributed Monolith |
|---|---|---|
| Deploy service A, apakah perlu deploy B juga? | Tidak — independent | Ya — tightly coupled |
| Database sharing antar service | Tidak — DB terpisah | Ya — shared DB |
| Tim yang maintain service | Satu tim per service | Tim sama maintain semua |
| API contract changes | Versioned, backward compat | Breaking change, semua harus update |
| Failure isolation | Service A fail, B masih jalan | Service A fail, semua terpengaruh |
Kapan Monolith Lebih Tepat untuk Konteks Indonesia
# Struktur yang recommended untuk startup 3-10 dev
src/
├── modules/
│ ├── auth/ # Isolated module — punya domain logic sendiri
│ │ ├── domain/
│ │ ├── application/
│ │ └── infrastructure/
│ ├── orders/
│ ├── payments/ # Interface ke Midtrans
│ └── notifications/ # Interface ke WhatsApp/email
├── shared/
│ ├── database/ # Shared DB — tapi accessed via module interfaces
│ └── events/ # Internal event bus — siapkan untuk extract ke service
└── main.ts
# Rules:
# - Modul tidak import langsung dari modul lain
# - Komunikasi via interface/event, bukan direct function call
# - Ini membuat extract ke microservice jauh lebih mudah nantiJika Anda INGIN microservices, ubah struktur tim dulu — baru arsitekturnya akan natural mengikuti. Bentuk cross-functional squad yang autonomous, beri mereka ownership penuh atas domain tertentu, dan microservices akan emerge organically.
Kesimpulan
Microservices bukan tentang teknologi — ini tentang organizational design. Untuk tim Indonesia yang kebanyakan masih di bawah 20 developer, modular monolith dengan internal boundaries yang jelas hampir selalu lebih pragmatis dari distributed microservices.
Kalau bisa digambarkan sebagai "satu tim yang maintain semuanya," arsitekturnya sebaiknya juga satu unit yang bisa di-deploy sekaligus.