Go Fiber: Batas Modular Monolith sebelum Pindah ke Multi-Service

Go Fiber sangat cocok untuk membangun backend yang cepat, sederhana, dan efisien. Namun pertanyaan pentingnya bukan apakah aplikasi Anda bisa dipecah menjadi multi-service, melainkan kapan pemisahan itu benar-benar memberi manfaat dibanding menambah kompleksitas baru.

Dalam banyak kasus, modular monolith adalah pilihan yang lebih sehat lebih lama daripada yang sering diasumsikan. Selama domain masih bisa dipisahkan secara logis di dalam satu codebase, rilis belum menjadi bottleneck, kebutuhan scaling antar domain belum jauh berbeda, dan kegagalan satu fitur belum perlu diisolasi secara keras, memecah aplikasi terlalu dini justru menambah biaya deployment, observability, debugging, dan koordinasi tim.

Artikel ini membahas batas praktis modular monolith di Go Fiber, sinyal kapan harus bertahan, kapan mulai memecah, serta bagaimana migrasi bertahap tanpa jatuh ke premature decomposition.

Apa yang dimaksud modular monolith di Go Fiber?

Modular monolith adalah aplikasi tunggal yang dideploy sebagai satu unit, tetapi di dalamnya domain dipisahkan dengan batas modul yang jelas: misalnya user, catalog, order, billing, dan notification. Setiap modul idealnya punya handler, service, repository, dan kontrak internal sendiri.

Di Go Fiber, pendekatan ini biasanya berarti:

• Satu binary aplikasi.
• Satu pipeline deployment utama.
• Komunikasi antar modul lewat pemanggilan fungsi/interface internal, bukan HTTP antar service.
• Database bisa satu cluster yang sama, tetapi akses tabel dipisahkan per domain semampunya.

Keuntungan utamanya adalah latensi rendah, debugging lebih mudah, setup operasional sederhana, dan perubahan lintas domain bisa dilakukan dalam satu pull request. Kekurangannya muncul ketika batas domain mulai bocor, kecepatan tim menurun karena semua orang berebut codebase yang sama, atau ketika kebutuhan operasional antar domain makin berbeda.

Kapan Go Fiber masih cocok sebagai modular monolith?

Jangan buru-buru memecah layanan hanya karena aplikasi tumbuh. Modular monolith masih sangat layak jika beberapa kondisi berikut masih benar.

1. Perubahan lintas domain masih sering dan normal

Jika alur bisnis utama masih sering menyentuh beberapa domain sekaligus, monolith biasanya lebih efisien. Contoh backend e-commerce: membuat order mungkin perlu validasi user, reservasi stok, perhitungan diskon, dan pembuatan invoice. Selama aturan ini masih berubah cepat, menyimpannya dalam satu codebase mengurangi friction koordinasi, versioning API internal, dan sinkronisasi schema/event.

2. Rilis masih lancar dan tidak jadi bottleneck

Jika satu aplikasi Go Fiber masih bisa dirilis beberapa kali sehari atau seminggu tanpa antrean tim, rollback mudah, dan blast radius perubahan masih terkendali, itu tanda monolith belum menjadi masalah utama. Banyak tim salah diagnosis: mereka mengira skala traffic menuntut microservices, padahal bottleneck sebenarnya ada di proses review, test coverage buruk, atau migrasi database yang berisiko.

3. Kebutuhan scaling antar modul belum sangat berbeda

Kalau semua domain relatif tumbuh bersama, satu deployment masih masuk akal. Misalnya API admin, catalog, dan order semuanya naik secara proporsional. Anda belum mendapat manfaat besar dari memisahkan service hanya untuk menskalakan satu bagian.

4. Tim masih kecil atau ownership belum stabil

Multi-service membutuhkan ownership yang jelas. Kalau tim masih 3-8 engineer dan boundary tanggung jawab belum mapan, memecah service terlalu cepat sering menghasilkan layanan kecil yang tetap dikerjakan orang yang sama, tetapi dengan beban operasional berkali-kali lipat.

5. Observability dan operasi dasar belum matang

Jika logging terstruktur, tracing, metrics, correlation ID, health check, dan incident response di satu aplikasi saja belum rapi, maka memecah menjadi banyak service biasanya memperburuk keadaan. Masalah yang sama akan tersebar ke lebih banyak proses, lebih banyak dashboard, dan lebih banyak jalur kegagalan.

Sinyal konkret kapan mulai layak pindah ke multi-service

Keputusan memecah sebaiknya dipicu oleh masalah nyata yang berulang, bukan preferensi arsitektur. Berikut sinyal yang lebih dapat dipercaya.

1. Bottleneck rilis mulai menghambat tim

Ini salah satu sinyal paling kuat. Gejalanya antara lain:

• Satu tim harus menunggu jadwal rilis tim lain.
• Perubahan kecil tertahan karena paket besar belum siap.
• Rollback satu fitur memaksa rollback fitur lain yang sebenarnya sehat.
• Test suite makin lama dan kegagalan unrelated sering memblokir deploy.

Jika modul tertentu secara konsisten ingin dirilis dengan ritme berbeda, itu tanda pemisahan deployment bisa memberi nilai nyata.

2. Coupling domain sudah menjadi beban maintainability

Coupling bukan sekadar ada pemanggilan antar package. Yang perlu diwaspadai adalah ketika aturan domain bercampur tanpa batas yang tegas. Contoh:

• Modul order langsung mengubah tabel billing dan notification.
• Handler HTTP berisi logika bisnis lintas domain.
• Repository satu modul dipakai bebas oleh modul lain.
• Perubahan kecil di domain A sering merusak domain B dan C.

Jika coupling ini tidak bisa diselesaikan dengan refactor internal, memisahkan service bisa membantu memaksa kontrak yang lebih jelas. Tapi perlu diingat: service boundary yang buruk hanya memindahkan kekacauan dari function call menjadi network call.

3. Kebutuhan scaling sudah jelas berbeda

Contoh nyata: modul search menerima traffic baca sangat tinggi, sedangkan billing rendah tapi sensitif. Atau modul webhook ingestion butuh concurrency tinggi dan tahan lonjakan, sementara API admin tidak. Jika satu binary memaksa Anda menskalakan semua komponen bersama-sama, biaya infrastruktur bisa membengkak.

Pemisahan masuk akal jika:

• Profil CPU/memori antar domain sangat berbeda.
• Satu modul membutuhkan autoscaling agresif, yang lain tidak.
• Satu modul butuh worker/background processing khusus.
• Satu modul memiliki dependency berat yang tidak layak dibawa seluruh aplikasi.

4. Isolasi kegagalan mulai menjadi kebutuhan operasional

Pada modular monolith, bug kebocoran memori, deadlock, goroutine leak, atau panic yang tidak tertangani dapat memengaruhi seluruh proses. Jika domain tertentu berisiko tinggi—misalnya integrasi webhook pihak ketiga, PDF generation, atau sinkronisasi partner—Anda mungkin ingin mengisolasi failure domain tersebut ke service atau worker terpisah.

Namun jangan menyamakan semua masalah reliability dengan kebutuhan microservices. Kadang memindahkan proses berat ke job queue atau worker terpisah sudah cukup tanpa memecah API utama menjadi banyak service.

5. Ownership tim sudah stabil per domain

Multi-service lebih efektif bila ada tim yang benar-benar memiliki domain, SLA, on-call, dan backlog-nya sendiri. Tanpa ownership jelas, service justru menjadi tumpukan dependency antar tim yang sulit diubah.

6. Kebutuhan compliance atau security menuntut pemisahan

Contohnya domain pembayaran atau data sensitif perlu akses, audit trail, dan kontrol jaringan yang lebih ketat. Dalam kondisi ini, pemisahan service kadang dibutuhkan bukan karena performa, tetapi karena batas keamanan dan tata kelola.

Trade-off teknis yang sering diremehkan

Latensi antarproses bukan sekadar soal cepat atau lambat

Di modular monolith, komunikasi antar modul adalah function call dalam memori proses yang sama. Setelah dipisah menjadi multi-service, panggilan berubah menjadi HTTP/gRPC/message broker. Ini menambah:

• Latensi jaringan.
• Potensi timeout dan retry storm.
• Kompleksitas idempotency.
• Kegagalan parsial: request berhasil di service A tapi gagal di B.

Masalah utamanya bukan hanya penambahan milidetik, tetapi perubahan model kegagalan. Code yang tadinya sinkron dan transaksional menjadi terdistribusi dan jauh lebih sulit dipastikan konsistensinya.

Observability jadi kebutuhan wajib, bukan bonus

Monolith dengan log sederhana kadang masih bisa di-debug. Pada multi-service, tanpa trace lintas service, structured logging, request ID, metrics per endpoint, dan alert yang masuk akal, investigasi incident akan lambat. Sering kali tim memecah service sebelum siap memonitor perilaku sistem secara menyeluruh.

Database coupling sering tetap ada meski service sudah dipisah

Kesalahan umum adalah memecah aplikasi, tetapi semua service masih membaca dan menulis tabel yang sama. Hasilnya Anda mendapat biaya jaringan dan deployment tambahan tanpa otonomi domain yang nyata. Jika data ownership belum bisa dipisahkan, biasanya lebih aman bertahan sebagai modular monolith sambil merapikan boundary internal.

Kompleksitas deployment naik lebih cepat daripada perkiraan

Satu service tambahan berarti pipeline build baru, environment variable baru, health check, autoscaling policy, dashboard, log retention, alert, secret management, network policy, rollback strategy, dan dokumentasi. Ini biaya tetap yang sering tidak dihitung saat diskusi arsitektur.

Matriks keputusan: bertahan atau mulai pecah?

Gunakan matriks sederhana berikut untuk menilai kondisi aplikasi Go Fiber Anda.

Heuristik praktisnya:

• Jika hanya 1-2 faktor di kolom kanan yang terasa, jangan pecah dulu.
• Jika 4 atau lebih faktor di kolom kanan terjadi berulang selama beberapa siklus rilis, evaluasi pemisahan domain tertentu.
• Mulailah dari domain dengan boundary paling jelas dan kebutuhan operasional paling berbeda.

Contoh struktur proyek Go Fiber untuk modular monolith

Struktur berikut menjaga batas domain tanpa over-engineering. Tujuannya bukan membuat folder sebanyak mungkin, tetapi memisahkan tanggung jawab dan mencegah akses lintas domain yang liar.

./cmd/api/main.go
./internal/platform/config
./internal/platform/http
./internal/platform/db
./internal/platform/logger
./internal/shared/events
./internal/shared/errs
./internal/modules/user
./internal/modules/user/http
./internal/modules/user/service
./internal/modules/user/repository
./internal/modules/user/model
./internal/modules/catalog
./internal/modules/catalog/http
./internal/modules/catalog/service
./internal/modules/catalog/repository
./internal/modules/order
./internal/modules/order/http
./internal/modules/order/service
./internal/modules/order/repository
./internal/modules/order/model
./internal/modules/billing
./internal/modules/billing/http
./internal/modules/billing/service
./internal/modules/billing/repository

Prinsip pentingnya:

• Handler hanya menangani HTTP concern: parsing request, validasi dasar, response code.
• Service memegang logika bisnis domain.
• Repository mengurusi persistence.
• Modul lain berinteraksi lewat interface/service, bukan langsung mengakses repository atau tabel internal.

Contoh registrasi route dan dependency injection yang tetap modular:

package main

import (
    "github.com/gofiber/fiber/v2"
)

type UserService interface {
    GetProfile(userID string) (any, error)
}

type OrderService interface {
    CreateOrder(userID string, req CreateOrderRequest) (any, error)
}

type AppModules struct {
    UserHandler  *UserHandler
    OrderHandler *OrderHandler
}

func registerRoutes(app *fiber.App, m AppModules) {
    api := app.Group("/api")

    user := api.Group("/users")
    user.Get("/:id", m.UserHandler.GetProfile)

    order := api.Group("/orders")
    order.Post("/", m.OrderHandler.Create)
}

Struktur ini masih monolith, tetapi cukup disiplin untuk memudahkan ekstraksi domain nanti.

Praktik yang membantu menjaga monolith tetap sehat

• Hindari package utils generik yang kemudian dipakai semua modul untuk logika bisnis.
• Jangan biarkan satu modul membaca tabel domain lain secara langsung jika bisa dihindari.
• Tambahkan test di level service untuk aturan bisnis penting.
• Gunakan event internal atau callback terkontrol untuk side effect, bukan chain pemanggilan liar dari handler ke banyak modul.
• Standarkan error mapping dan logging agar investigasi tetap mudah saat aplikasi membesar.

Skenario nyata: kapan modular monolith mulai terasa sempit?

Kasus 1: Backend e-commerce menengah

Misalkan aplikasi Go Fiber memiliki domain catalog, cart, order, payment, dan notification.

Masih cocok monolith jika:

• Perubahan checkout masih sering memengaruhi cart, promo, dan order sekaligus.
• Traffic belum menunjukkan modul tertentu jauh lebih dominan.
• Semua engineer masih aktif di sebagian besar domain.

Mulai layak dipisah jika:

• Notification dan webhook payment sering error dan mengganggu API utama.
• Catalog/search butuh scaling baca jauh lebih tinggi daripada order.
• Payment perlu security boundary dan audit lebih ketat.

Dalam kasus ini, Anda tidak harus langsung memecah semua domain. Notification worker atau payment integration service bisa menjadi kandidat awal, sementara order dan cart tetap di monolith.

Kasus 2: SaaS B2B dengan banyak integrasi eksternal

Jika modul sinkronisasi partner, import/export data, dan webhook ingestion memiliki pola kerja berat serta retry kompleks, modul-modul itu sering lebih baik dipisah lebih dulu daripada API inti. Ini memberi isolasi kegagalan tanpa menghancurkan coherence domain utama.

Migrasi bertahap yang aman: jangan mulai dari pemisahan jaringan

Strategi terbaik biasanya bukan langsung membangun banyak service, tetapi menyiapkan extractable monolith. Urutannya bisa seperti ini.

1. Rapikan boundary di dalam monolith

Sebelum memecah, pastikan modul punya API internal yang jelas. Kalau domain belum rapi di dalam satu proses, ia hampir pasti tidak akan rapi setelah dipisah.

• Pindahkan logika bisnis keluar dari handler.
• Batasi akses repository lintas modul.
• Definisikan interface antar domain yang eksplisit.

2. Pisahkan side effect asinkron terlebih dahulu

Sering kali bottleneck bukan pada domain utama, tetapi pekerjaan samping seperti email, webhook, PDF, indexing, atau sinkronisasi pihak ketiga. Memindahkan ini ke worker atau queue memberi manfaat besar tanpa perlu memecah API inti.

Jika kebutuhan Anda adalah isolasi beban dan retry, worker terpisah sering lebih murah daripada microservice penuh.

3. Gunakan kontrak internal seolah-olah modul itu service

Walau masih satu codebase, perlakukan modul kandidat sebagai unit mandiri: punya interface input/output, DTO sendiri, logging sendiri, dan test integrasi yang jelas. Ini mengurangi risiko saat nanti endpoint internal berubah menjadi HTTP/gRPC.

4. Ekstrak domain dengan boundary paling jelas

Pilih domain yang:

• Paling sedikit dependency sinkron ke domain lain.
• Punya kebutuhan scaling atau reliability berbeda.
• Dimiliki tim yang jelas.
• Memiliki data ownership yang bisa dipisah.

Biasanya kandidat yang baik adalah notification, search indexing, media processing, webhook ingestion, atau billing integration. Kandidat yang lebih sulit adalah order orchestration utama jika masih sangat terkait dengan banyak domain internal.

5. Hindari distributed transaction sebagai langkah awal

Saat domain baru diekstrak, jangan buru-buru menuntut konsistensi kuat lintas service untuk semua operasi. Mulailah dari use case yang tahan eventual consistency. Jika Anda memaksa transaksi lintas service terlalu dini, kompleksitas akan melonjak.

6. Siapkan observability sebelum traffic produksi dialihkan

Minimal pastikan ada:

• Request ID/correlation ID lintas boundary.
• Structured logging konsisten.
• Metrics latency, error rate, throughput.
• Trace untuk request yang melewati beberapa komponen.
• Health check dan timeout yang jelas.

Contoh heuristik keputusan sederhana

Gunakan daftar pertanyaan berikut saat review arsitektur triwulanan:

1. Apakah satu domain perlu dirilis jauh lebih sering daripada yang lain?
2. Apakah satu domain memiliki pola traffic, CPU, atau memori yang sangat berbeda?
3. Apakah kegagalan domain tersebut perlu diisolasi dari API utama?
4. Apakah tim yang memilikinya sudah jelas?
5. Apakah data ownership-nya bisa dipisah tanpa banyak query silang?
6. Apakah observability lintas proses sudah cukup matang?
7. Apakah manfaat pemisahan lebih besar daripada biaya operasional tambahan?

Jika jawaban “ya” dominan, Anda punya kandidat kuat untuk diekstrak. Jika banyak jawaban masih “belum”, bertahan di modular monolith biasanya lebih rasional.

Kesalahan umum saat transisi dari Go Fiber modular monolith ke multi-service

• Memecah berdasarkan folder, bukan domain bisnis. Hasilnya service boundary artifisial yang tetap saling tergantung.
• Mengabaikan data ownership. Service terpisah tetapi masih berbagi tabel yang sama.
• Tidak menetapkan timeout, retry, dan idempotency. Ini cepat berubah menjadi incident berulang.
• Memindahkan sinkronisasi internal menjadi HTTP call tanpa alasan kuat. Anda mendapat latency dan failure mode tambahan tanpa manfaat jelas.
• Kurang observability. Saat ada error lintas service, tim tidak bisa mengikuti jejak request.
• Mengira microservice otomatis mempercepat tim. Tanpa ownership dan kontrak yang baik, justru sebaliknya.

Debugging dan evaluasi sebelum memutuskan pecah

Sebelum mengubah arsitektur, kumpulkan bukti operasional:

• Endpoint mana yang paling sering lambat?
• Modul mana yang paling sering menyebabkan incident?
• Apakah masalah berasal dari CPU, query database, lock, dependency eksternal, atau proses rilis?
• Berapa sering perubahan satu domain memaksa retest seluruh sistem?

Sering kali profiling, query optimization, background worker, cache, atau refactor boundary internal sudah cukup menyelesaikan masalah tanpa perlu multi-service.

Kesimpulan

Go Fiber modular monolith sebaiknya dipertahankan selama ia masih memberi kecepatan pengembangan, deployment sederhana, latensi rendah, dan maintainability yang dapat dikendalikan. Pindah ke multi-service layak dipertimbangkan saat bottleneck rilis nyata, kebutuhan scaling antar domain sudah berbeda, isolasi kegagalan diperlukan, ownership tim matang, dan batas domain sudah cukup jelas untuk dipisahkan.

Kuncinya adalah memecah berdasarkan kebutuhan operasional dan batas domain yang terbukti, bukan berdasarkan tren arsitektur. Mulailah dengan monolith yang modular, rapikan kontrak internal, ekstrak domain yang benar-benar layak, dan pastikan observability siap sebelum kompleksitas terdistribusi masuk ke produksi.