All writing
2 min read

Microservices bukan jawaban untuk tim kecil: bukti dari 34 + 130 modul monolith

Dua project terbesar yang aku pegang — 34 modul dan 130+ modul — jalan sebagai monolith. Modular iya, microservices tidak. Ini alasannya.

#opinion#architecture#monolith

TL;DR

Untuk tim kecil, modular monolith hampir selalu lebih baik daripada microservices. Kamu dapat boundary-nya, tanpa bayar coordination overhead.

Setup

Dua project terbesar yang pernah aku pegang:

  1. ERP 34 modul — Accounting, POS, Commerce, Payroll, CRM, integrasi TikTok Shop/Shopee/WooCommerce. Satu Laravel app.
  2. Enterprise HRIS 130+ modul — Payroll, KPI, Appraisal, Recruitment, sampai Layoff. Satu Laravel app juga. RabbitMQ dan MongoDB ada di dalamnya, tapi sebagai sidecar, bukan service terpisah.

Keduanya monolith. Keduanya jalan. Tidak ada Kubernetes yang menangis di malam hari.

Thesis

Microservices menyelesaikan masalah organisasi, bukan masalah teknis. Kalau tim-mu kecil, kamu tidak punya masalah organisasi yang perlu diselesaikan. Kamu justru menciptakan masalah baru: distributed debugging, network failure, versioned API contracts, dan deploy orchestration.

Boundary yang kamu butuhkan:  modul yang tidak saling injek
Yang microservices berikan:   boundary + jaringan + retry + tracing + deploy pipeline per service
Yang kamu bayar:              semua baris kedua, padahal cuma butuh baris pertama

Kenapa orang tidak setuju (dan kenapa mereka salah untuk konteks ini)

Argumen umum pro-microservices: independent scaling, team autonomy, fault isolation.

Semua benar — untuk organisasi besar. Netflix butuh itu. Tim 5–15 engineer tidak.

Independent scaling? Modul ERP yang paling berat bebannya adalah Commerce sync — dan itu diselesaikan dengan queue worker, bukan dengan memisahkan service. RabbitMQ di HRIS menangani bulk payroll secara async. Satu app, worker tinggal di-scale jumlah process-nya.

Fault isolation? Ya, satu modul panic bisa jatuhkan satu app. Tapi observability stack (Sentry + Telescope) membuat root cause ketahuan dalam menit, dan rollback satu deploy lebih cepat daripada rollback 8 service.

Real numbers dari pengalamanku

  • ERP: 34 modul, satu repo, satu deploy. Client bisa aktifkan subset modul tanpa deploy terpisah.
  • HRIS: 130+ modul (80 admin + 50 API), dual database (PostgreSQL + MongoDB), RabbitMQ untuk async, MQTT untuk realtime. Semua dalam satu monolith Laravel 11.
  • Pola yang berulang: yang dibutuhkan selalu “isolation kode”, bukan “isolation network”.

Catatan: ini data dari dua project yang aku kerjakan, bukan survei industri. Sample size = 2. Tapi keduanya production, dan keduanya ukurannya tidak kecil.

“Tapi nanti kalau scale-nya besar gimana?”

Monolith modular tidak menutup jalan ke service extraction. Justru sebaliknya: karena boundary modul sudah jelas (tiap modul punya migration, model, dan service provider sendiri, komunikasi lewat events), modul yang benar-benar butuh scale independen bisa di-extract kelak dengan effort yang masuk akal.

Extract service karena kebutuhan terukur, bukan karena kekhawatiran di hari pertama.

Edge cases — kapan opini ini tidak berlaku

  • Tim sudah puluhan engineer dan multiple squad yang saling blocking. Baru masuk akal.
  • Ada kebutuhan compliance yang memaksa data isolation di level infra, bukan level kode.
  • Satu komponen punya karakteristik load yang benar-benar beda (misal video transcoding) — extract itu saja, sisanya tetap monolith.

Kesimpulan

Modular iya. Microservices belum. Extract nanti, kalau datanya memaksa.

References

All writingBack to home