Go Fiber: Kapan Tetap Monolith Modular vs Pecah ke Service

Jawaban singkatnya: jika aplikasi Go Fiber Anda masih bisa dijaga dengan batas modul yang jelas, satu database utama, deployment yang tidak saling mengunci, dan tim belum kewalahan oleh coupling lintas domain, maka monolith modular biasanya masih cukup. Pecah ke service baru layak ketika ada batas domain yang stabil, kebutuhan scaling atau rilis yang berbeda, serta tim siap menanggung biaya observability, jaringan, deployment, dan konsistensi data yang lebih kompleks.

Banyak tim terlalu cepat mengasosiasikan pertumbuhan aplikasi dengan keharusan memakai microservices. Dalam praktik backend Go Fiber, keputusan yang lebih penting bukan “monolith vs microservices” secara abstrak, tetapi apakah domain sudah cukup matang untuk dipisah, dan apakah biaya operasional tambahan sebanding dengan masalah yang diselesaikan. Artikel ini fokus pada konteks Fiber: bagaimana menyusun monolith modular yang sehat, kapan mengekstrak service kecil, dan sinyal kapan pemecahan justru terlalu cepat.

Memahami konteks: monolith modular bukan berarti kode berantakan

Monolith modular adalah satu aplikasi yang di-deploy sebagai satu unit, tetapi di dalamnya domain dipisah dengan batas paket, interface, dan dependency yang jelas. Untuk aplikasi Fiber, ini sering menjadi titik tengah yang sangat efektif:

• Satu proses aplikasi, satu pipeline deployment, dan biasanya satu repositori.
• Routing HTTP tetap sederhana karena semua endpoint masih berada di satu aplikasi Fiber.
• Komunikasi antar domain tetap lewat pemanggilan fungsi atau interface, bukan lewat jaringan.
• Transaksi database lintas domain masih lebih mudah jika memang harus dilakukan.

Masalah umum bukan pada bentuk monolith-nya, tetapi pada implementasinya: semua package saling impor, query SQL tersebar di handler, logic bisnis bercampur dengan transport HTTP, dan tidak ada batas domain yang tegas. Jika itu yang terjadi, memecah ke service terlalu dini biasanya hanya memindahkan kekacauan dari satu proses ke banyak proses.

Trade-off teknis: monolith modular vs service terpisah

1. Batas domain dan coupling

Monolith modular cocok ketika domain masih sering berubah dan hubungan antar fitur masih rapat. Misalnya order, payment, inventory, dan user masih berbagi aturan bisnis yang sering direvisi bersama. Di fase ini, memecah service terlalu cepat berisiko menghasilkan batas service yang salah.

Service terpisah masuk akal ketika satu domain punya lifecycle yang lebih mandiri. Contoh: modul notifikasi memiliki kebutuhan rilis, beban kerja, dan ketergantungan yang berbeda dari API utama. Jika perubahan pada notifikasi tidak seharusnya mengganggu order API, ekstraksi bisa berguna.

Masalah coupling yang perlu diperhatikan:

• Jika modul A harus tahu tabel internal modul B, berarti batas domain belum sehat.
• Jika perubahan kecil memaksa rebuild banyak package, periksa arah dependency.
• Jika domain dipisah ke service tetapi masih butuh query join lintas database untuk satu request, pemisahan belum matang.

2. Deployment dan frekuensi rilis

Monolith modular memberi pipeline yang lebih sederhana: build satu binary Go, deploy satu artefak, rollback satu unit. Ini sangat cocok untuk tim kecil sampai menengah.

Service terpisah memberi deployment independence, tetapi hanya bernilai jika domain memang sering dirilis secara berbeda. Bila semua perubahan tetap harus dikoordinasikan bersama, memecah service tidak memberi manfaat besar dan justru menambah overhead CI/CD.

Pertanyaan praktis:

• Apakah modul tertentu sering butuh dirilis sendiri tanpa menunggu aplikasi lain?
• Apakah kegagalan deploy satu domain seharusnya tidak menghambat domain lain?
• Apakah proses rollback saat ini sulit karena perubahan banyak domain tercampur?

3. Observability dan debugging

Di monolith modular, tracing masalah biasanya lebih lurus: satu log stream, satu process metric, satu jejak stack, dan lebih sedikit hop jaringan. Ini sangat membantu saat tim belum punya observability yang matang.

Begitu Anda memecah ke service, Anda wajib siap dengan:

• Correlation ID antar request.
• Structured logging yang konsisten.
• Distributed tracing untuk melihat hop antar service.
• Monitoring timeout, retry, dan error rate jaringan.

Tanpa ini, bug yang tadinya mudah direproduksi di monolith bisa berubah menjadi masalah intermiten yang sulit dilacak.

Jika tim belum disiplin pada logging, metric, dan tracing di satu aplikasi Fiber, memecah ke banyak service biasanya memperburuk MTTR, bukan memperbaikinya.

4. Latency jaringan dan reliability

Pemanggilan fungsi antar modul di monolith jauh lebih murah daripada RPC atau HTTP antar service. Saat satu endpoint Fiber harus memanggil beberapa service sinkron, latency total bisa naik dan failure mode bertambah:

• Timeout jaringan
• Connection pool habis
• Retry ganda yang memperparah beban
• Cascading failure saat satu service lambat

Untuk alur request yang sensitif terhadap latency, tetap di monolith modular sering lebih masuk akal, terutama jika workflow membutuhkan beberapa langkah sinkron dalam satu jalur request-response.

5. Konsistensi data dan transaksi

Ini salah satu pembeda terpenting. Dalam monolith modular, transaksi ACID lintas modul masih mungkin selama berbagi database dan boundary-nya belum dipisah total. Misalnya membuat order dan mengurangi stok dalam satu transaksi bisa lebih sederhana.

Pada service terpisah, setiap service idealnya memiliki ownership data sendiri. Konsekuensinya:

• Join lintas domain menjadi lebih sulit.
• Transaksi lintas service tidak lagi sederhana.
• Anda perlu pola seperti outbox, event-driven integration, atau kompensasi proses.

Jika bisnis Anda masih sangat bergantung pada transaksi sinkron yang konsisten lintas domain, memecah terlalu cepat dapat memperumit sistem lebih dari yang dibutuhkan.

6. Testing

Monolith modular memudahkan integration test lokal: satu proses, database test, dan mock seperlunya. Ini sangat efisien untuk menjaga kecepatan feedback.

Service terpisah menuntut lapisan testing tambahan:

• Contract test antar service
• Integration test dengan dependency nyata atau container
• Test untuk retry, timeout, dan idempotency
• Test kompatibilitas versi API

Kalau suite test Anda di monolith saja belum stabil, arsitektur service akan menambah permukaan masalah.

7. Ownership tim dan kompleksitas operasional

Pemisahan service sering berhasil jika ada ownership tim yang jelas. Bila satu tim kecil masih mengerjakan semua domain, banyak service berarti lebih banyak repository, deployment, dashboard, secret, dan kebijakan operasional yang harus dipelihara orang yang sama.

Secara operasional, service terpisah menambah:

• Konfigurasi environment per service
• Manajemen secret dan koneksi database
• Health check dan autoscaling per service
• Versioning API internal
• Runbook insiden yang lebih banyak

Jadi, ekstraksi service sebaiknya bukan didorong oleh tren, tetapi oleh kebutuhan teknis dan organisasi yang nyata.

Kapan monolith modular di Go Fiber masih cukup?

Berikut indikator kuat bahwa Anda sebaiknya tetap di monolith modular dulu:

• Satu tim masih menguasai sebagian besar domain.
• Perubahan lintas modul masih sering terjadi, artinya boundary domain belum stabil.
• Satu database utama masih masuk akal dan tidak menjadi bottleneck arsitektural utama.
• Kebutuhan transaksi lintas domain tinggi dan sulit diubah ke model eventual consistency.
• Traffic meningkat tetapi scaling horizontal untuk seluruh aplikasi masih cukup.
• Rilis masih bisa dikoordinasikan tanpa menjadi hambatan utama.
• Observability belum matang untuk debugging terdistribusi.
• Masalah maintainability sebenarnya berasal dari struktur kode yang buruk, bukan dari bentuk deploy tunggal.

Dalam banyak kasus, masalah yang tampak seperti “butuh microservices” sebenarnya lebih tepat diselesaikan dengan:

• Memisahkan package per domain
• Menerapkan interface untuk repository dan service
• Memindahkan logic bisnis keluar dari handler Fiber
• Menghapus dependency silang yang tidak perlu
• Membuat modul notifikasi, billing, atau reporting lebih terisolasi di dalam monolith

Kapan perlu mulai memecah ke service?

Ekstraksi service layak dipertimbangkan ketika beberapa indikator ini muncul bersamaan, bukan hanya satu:

• Domain tertentu punya beban kerja sangat berbeda, misalnya notifikasi async atau image processing, sehingga pola scaling-nya berbeda dari API utama.
• Kebutuhan rilis independen tinggi, dan koordinasi deploy dalam satu aplikasi mulai menghambat.
• Batas domain stabil, termasuk ownership data dan kontrak API-nya.
• Risiko perubahan satu domain tidak boleh menjatuhkan domain lain.
• Tim berbeda memiliki ownership yang jelas terhadap domain yang dipisahkan.
• Observability, CI/CD, dan operasional sudah cukup matang untuk mengelola service tambahan.
• Dependensi eksternal khusus pada satu domain membuat binary utama terlalu berat atau kompleks.

Contoh yang cukup sering masuk akal untuk diekstrak lebih dulu dari aplikasi Fiber utama:

• Notification service
• File/media processing
• Webhook delivery worker
• Reporting atau export job berat

Contoh yang sering belum layak dipisah terlalu cepat:

• Order dan payment yang masih sangat sinkron dan transaksional
• User dan auth yang masih erat dengan banyak modul internal
• Catalog dan inventory yang masih bergantung pada query gabungan kompleks untuk endpoint utama

Anti-pattern: memecah terlalu cepat

1. Service dipisah, database tetap dipakai bersama

Ini anti-pattern yang sangat umum. Anda membayar biaya jaringan dan deployment terpisah, tetapi tetap memiliki coupling skema database yang kuat. Akibatnya, perubahan skema di satu service bisa merusak service lain diam-diam.

2. Boundary dibuat berdasarkan folder, bukan domain

Memisah “user-service”, “product-service”, “order-service” terdengar rapi, tetapi jika alur bisnis sebenarnya saling tumpang tindih dan sering berubah, Anda hanya membuat boundary artifisial.

3. Synchronous call chain terlalu panjang

Satu request masuk ke API gateway lalu memanggil service A, B, C, lalu kembali lagi. Ini membuat latency dan failure rate sulit dikendalikan. Jika flow harus tetap sinkron dan pendek, monolith modular sering lebih tepat.

4. Memecah karena ukuran codebase, bukan karena dependency yang buruk

Codebase besar belum tentu alasan untuk membuat service. Kadang masalah utamanya adalah package boundary yang jelek, bukan deploy unit yang terlalu besar.

5. Event-driven dipakai untuk semua hal tanpa kebutuhan nyata

Asynchronous event memang berguna, tetapi juga menambah kompleksitas debugging, idempotency, ordering, dan reprocessing. Jangan memaksakan event jika kebutuhan bisnis masih menuntut hasil sinkron yang jelas.

Struktur proyek Go Fiber untuk monolith modular

Contoh berikut menunjukkan monolith modular yang masih satu aplikasi Fiber, tetapi domain dipisah jelas.

myapp/
├── cmd/
│   └── api/
│       └── main.go
├── internal/
│   ├── platform/
│   │   ├── config/
│   │   ├── db/
│   │   ├── logger/
│   │   └── httpx/
│   ├── order/
│   │   ├── delivery/
│   │   │   └── http/
│   │   ├── usecase/
│   │   ├── repository/
│   │   └── domain/
│   ├── payment/
│   │   ├── delivery/
│   │   │   └── http/
│   │   ├── usecase/
│   │   ├── repository/
│   │   └── domain/
│   └── inventory/
│       ├── delivery/
│       │   └── http/
│       ├── usecase/
│       ├── repository/
│       └── domain/
├── migrations/
├── go.mod
└── README.md

Prinsip pentingnya:

• Handler Fiber hanya menangani parsing request, validasi dasar, dan mapping response.
• Usecase menyimpan orchestration bisnis.
• Repository menangani akses data atau dependency eksternal.
• Domain berisi entity, aturan inti, atau kontrak penting.

Contoh wiring route yang sederhana:

package main

import (
    "log"

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

func main() {
    app := fiber.New()

    api := app.Group("/api")

    // orderHandler, paymentHandler, inventoryHandler
    // diinisialisasi dari dependency masing-masing modul
    // misalnya: orderhttp.RegisterRoutes(api, orderHandler)

    log.Fatal(app.Listen(":8080"))
}

Yang lebih penting daripada bentuk folder adalah arah dependency. Modul order boleh memanggil interface yang disediakan payment jika dibutuhkan, tetapi jangan sampai handler HTTP payment mengimpor repository order secara sembarangan. Jika terjadi, batas modul mulai bocor.

Contoh service kecil hasil ekstraksi dari aplikasi Fiber

Misalkan modul notifikasi menjadi kandidat kuat untuk dipisahkan karena asynchronous, integrasi provider eksternal, dan kebutuhan scaling berbeda. Struktur sederhananya bisa seperti ini:

notification-service/
├── cmd/
│   └── api/
│       └── main.go
├── internal/
│   ├── platform/
│   │   ├── config/
│   │   ├── logger/
│   │   └── queue/
│   ├── notification/
│   │   ├── delivery/
│   │   │   └── http/
│   │   ├── usecase/
│   │   ├── provider/
│   │   ├── repository/
│   │   └── domain/
│   └── worker/
├── go.mod
└── README.md

API utama tetap memakai Fiber, dan service notifikasi juga bisa memakai Fiber jika memang menyediakan endpoint internal seperti enqueue webhook, status delivery, atau health check. Namun jangan membuat service hanya untuk konsistensi framework; pastikan ada alasan domain dan operasionalnya.

Contoh klien internal dari monolith ke service notifikasi:

type NotificationClient interface {
    SendOrderCreated(ctx context.Context, req SendNotificationRequest) error
}

type HTTPNotificationClient struct {
    BaseURL string
    Client  *http.Client
}

func (c *HTTPNotificationClient) SendOrderCreated(ctx context.Context, req SendNotificationRequest) error {
    body, err := json.Marshal(req)
    if err != nil {
        return err
    }

    httpReq, err := http.NewRequestWithContext(ctx, http.MethodPost, c.BaseURL+"/internal/notifications/order-created", bytes.NewReader(body))
    if err != nil {
        return err
    }
    httpReq.Header.Set("Content-Type", "application/json")

    resp, err := c.Client.Do(httpReq)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    if resp.StatusCode >= 300 {
        return fmt.Errorf("notification service returned status %d", resp.StatusCode)
    }

    return nil
}

Begitu memakai komunikasi jaringan seperti ini, Anda perlu menambahkan timeout, retry yang hati-hati, idempotency bila request bisa terkirim ulang, dan logging dengan request ID. Inilah biaya nyata dari ekstraksi service.

Panduan keputusan praktis untuk engineer Fiber

Checklist keputusan: jangan pecah sebelum menjawab ini

1. Apakah domain yang akan dipisah punya ownership data yang jelas?
2. Apakah domain itu bisa beroperasi dengan kontrak API yang stabil?
3. Apakah kita siap menerima latency jaringan dan failure mode baru?
4. Apakah kebutuhan bisnis bisa menerima eventual consistency bila transaksi lintas domain tak lagi sederhana?
5. Apakah tim memiliki observability yang cukup untuk sistem terdistribusi?
6. Apakah service itu benar-benar perlu scaling atau rilis independen?
7. Apakah masalah saat ini tidak bisa diselesaikan lebih murah dengan refactor monolith modular?

Debugging tips saat aplikasi mulai tumbuh

Jika tetap monolith modular

• Audit import antar package untuk menemukan dependency silang yang tidak sehat.
• Buat test integration per domain, bukan hanya test handler.
• Pastikan context request mengalir ke repository atau client eksternal.
• Tambahkan logging terstruktur per modul agar bottleneck domain lebih terlihat.

Jika mulai mengekstrak service

• Mulai dari domain yang paling sedikit coupling sinkronnya.
• Jangan langsung pecah beberapa service sekaligus.
• Tetapkan timeout client dengan jelas; default tanpa batas adalah sumber insiden.
• Tambahkan idempotency untuk endpoint internal yang bisa terkena retry.
• Ukur error rate dan latency antar service sebelum dan sesudah ekstraksi.

Rekomendasi praktis

Untuk sebagian besar backend Go Fiber yang sedang tumbuh, mulailah dari monolith modular yang disiplin. Susun domain dengan batas yang jelas, jaga handler tetap tipis, pusatkan logic bisnis di layer usecase, dan hindari dependency silang yang bocor. Ini memberi kecepatan delivery, testing yang cepat, dan operasional yang jauh lebih sederhana.

Pecah ke service hanya ketika ada tekanan nyata: domain stabil, ownership jelas, kebutuhan scaling atau rilis independen terbukti, dan tim siap mengelola konsekuensi teknisnya. Jika belum, refactor monolith modular hampir selalu lebih murah, lebih aman, dan lebih mudah dikontrol daripada masuk terlalu cepat ke arsitektur terdistribusi.

Singkatnya, dalam konteks Go Fiber: kapan tetap monolith modular vs pecah ke service, pilih monolith modular sebagai default yang sehat. Ekstraksi service adalah langkah lanjutan yang harus dibenarkan oleh domain, data, dan operasional, bukan oleh asumsi bahwa aplikasi yang membesar pasti harus dipecah.