Next.js: Kapan Tetap Monolith dan Kapan Pecah ke Service

Jawaban singkatnya: untuk banyak tim kecil sampai menengah, Next.js full-stack monolith masih menjadi pilihan terbaik selama kebutuhan domain, traffic, dan proses operasional belum benar-benar menuntut pemisahan. Anda biasanya baru perlu pecah ke service ketika bottleneck utama bukan lagi pada kode aplikasi yang menyatu, melainkan pada ownership tim, isolasi scaling, kebutuhan background processing, integrasi internal yang makin kompleks, atau kebutuhan observability dan deployment yang tidak lagi nyaman ditangani dalam satu unit deploy.

Masalahnya, keputusan ini sering diambil terlalu cepat atau terlalu lambat. Jika memecah terlalu cepat, tim menanggung overhead deployment, tracing, auth antar-service, kontrak API, retry, dan debugging lintas jaringan. Jika terlambat, monolith bisa menjadi titik macet untuk scaling, release, dan pembagian tanggung jawab. Di artikel ini, kita bahas cara menilai batas tersebut secara praktis dalam konteks Next.js App Router, Route Handler/API, background job, cache, database, dan integrasi internal.

Apa yang dimaksud monolith di Next.js?

Dalam konteks Next.js, monolith biasanya berarti satu repository dan satu sistem deploy utama yang menangani:

• UI React/Server Components
• Routing aplikasi web
• Server-side data fetching
• Route Handler atau API internal
• Akses database
• Auth, cache, dan validasi

Dengan App Router, batas antara frontend dan backend memang menjadi lebih tipis. Anda bisa merender data di server, memanggil database langsung dari server-side code, dan menyediakan endpoint internal di route tertentu. Ini membuat monolith sangat efisien untuk banyak use case, terutama saat satu tim mengelola satu produk dengan domain bisnis yang belum terlalu besar.

Sebaliknya, pecah ke service berarti sebagian tanggung jawab dipindahkan ke aplikasi atau proses terpisah. Contohnya:

• service auth terpisah
• service billing terpisah
• worker/background job terpisah
• backend API terpisah yang dikonsumsi Next.js
• service internal untuk integrasi ERP, payment, atau sinkronisasi data

Pemisahan ini tidak harus langsung berarti microservices penuh. Sering kali bentuk paling realistis adalah modular monolith + beberapa service terpisah untuk kebutuhan spesifik.

Kapan Next.js monolith masih tepat?

1. Domain bisnis masih relatif sederhana

Jika alur bisnis utama masih fokus pada CRUD, autentikasi, dashboard, katalog, checkout sederhana, atau admin panel internal, monolith sering lebih efisien. Tim bisa mengubah UI, validasi, query database, dan endpoint tanpa harus menyelaraskan kontrak antar-service.

2. Satu tim masih memiliki ownership yang jelas

Kalau satu tim yang sama mengelola frontend dan backend produk, memisahkan service terlalu dini biasanya hanya memindahkan kompleksitas. Koordinasi mungkin tetap dilakukan oleh orang yang sama, tetapi sekarang harus melewati jaringan, auth service-to-service, dan pipeline deploy yang lebih banyak.

3. Beban traffic belum membutuhkan scaling berbeda

Tidak semua bagian sistem butuh scaling terpisah. Jika halaman web, API internal, dan akses database masih tumbuh dengan pola yang mirip, satu deployable unit sering cukup. Scaling terpisah lebih berguna jika ada bagian tertentu yang sangat berat, misalnya webhook ingestion, image processing, atau job sinkronisasi massal.

4. Observability dan debugging masih mudah dilakukan dalam satu tempat

Monolith punya keuntungan besar: satu codebase, satu log stream utama, satu proses request lifecycle yang lebih mudah diikuti. Ini penting untuk tim yang belum punya tracing lintas service, log correlation, atau incident response yang matang.

5. Anda masih sering mengubah model domain

Kalau struktur domain masih sering berubah, memecah service bisa membuat kontrak API cepat usang. Monolith lebih nyaman untuk fase eksplorasi karena perubahan schema, validasi, dan use case bisa dilakukan lebih cepat tanpa negosiasi antar-boundary.

6. Background job masih terbatas dan tidak kritikal

Jika job hanya berupa kirim email, sinkronisasi ringan, atau revalidasi cache, Anda belum tentu perlu service terpisah. Sering kali cukup dengan worker kecil yang masih satu repository atau memakai queue terpisah tanpa memecah seluruh backend.

Sinyal praktis: bila mayoritas perubahan fitur masih melibatkan halaman, validasi server, dan query database yang saling terkait erat, monolith biasanya masih pilihan yang sehat.

Kapan mulai perlu pecah ke service?

1. Ada bottleneck scaling yang tidak sama

Ini sinyal paling kuat. Contoh:

• trafik halaman web stabil, tetapi endpoint webhook menerima lonjakan tinggi
• render halaman ringan, tetapi proses ekspor laporan sangat berat
• user-facing request harus cepat, tetapi proses sinkronisasi vendor butuh retry panjang

Jika workload seperti ini tetap tinggal di jalur request utama Next.js, Anda akan sulit mengisolasi resource, timeout, dan kapasitas. Service atau worker terpisah memberi ruang untuk scaling sesuai karakter beban.

2. Background job sudah menjadi subsistem penting

Ketika proses asinkron bukan lagi pelengkap, melainkan inti sistem, pemisahan mulai masuk akal. Misalnya:

• pemrosesan invoice
• sinkronisasi stok lintas marketplace
• retry webhook pihak ketiga
• generasi file besar
• notifikasi multichannel

Job semacam ini perlu antrean, retry policy, dead-letter handling, idempotency, rate limiting, dan observability sendiri. Menaruh semua itu langsung di request/response Next.js biasanya berujung pada desain yang rapuh.

3. Integrasi internal atau eksternal makin kompleks

Jika aplikasi harus berbicara dengan banyak sistem internal, payment gateway, ERP, CRM, vendor shipping, atau data warehouse, Anda akan diuntungkan dengan anti-corruption layer berupa service khusus integrasi. Tujuannya bukan sekadar memecah kode, tetapi menjaga agar domain utama tidak tercampur dengan detail protokol vendor, format payload, retry, dan fallback.

4. Release cadence antar-area berbeda jauh

Jika tim produk web ingin deploy cepat, tetapi area billing atau fulfillment butuh prosedur lebih ketat, memisahkan service bisa mengurangi konflik proses rilis. Ini juga berguna ketika area tertentu butuh compliance, audit trail, atau kontrol akses yang lebih ketat.

5. Ownership tim mulai terbagi secara nyata

Pemisahan service paling masuk akal jika diikuti pemisahan ownership yang jelas. Kalau ada tim yang benar-benar bertanggung jawab atas domain billing, search, atau fulfillment, mereka akan lebih produktif dengan boundary yang stabil. Tetapi tanpa ownership yang jelas, service terpisah hanya menciptakan batas teknis tanpa manfaat organisasi.

6. Monolith mulai menghambat maintainability jangka panjang

Gejalanya antara lain:

• perubahan kecil sering memicu retest area yang luas
• dependency antar-modul sulit dipetakan
• query database lintas domain makin kacau
• API internal sulit distandarkan
• banyak logika domain bocor ke layer UI atau route handler

Jika masalah utamanya struktur kode, langkah pertama tidak harus microservices. Sering kali solusi terbaik adalah modularisasi internal dulu, baru ekstraksi service secara selektif.

Trade-off utama: monolith vs service terpisah

Konteks praktis di Next.js App Router

Route Handler dan API internal: bagus, tapi jangan dijadikan tempat semua hal

Route Handler di App Router cocok untuk:

• endpoint internal sederhana
• BFF (backend for frontend)
• validasi input sebelum akses database
• agregasi ringan data dari beberapa sumber

Namun, Route Handler bukan tempat ideal untuk semua workload. Hindari menjadikannya lokasi utama untuk:

• job panjang atau CPU-intensive
• proses retry kompleks
• integrasi vendor yang sering lambat atau tidak stabil
• logika domain besar yang dipakai banyak konsumen

Jika kebutuhan Anda mulai seperti itu, pertimbangkan memindahkan logika ke service layer internal atau worker terpisah, lalu Route Handler hanya menjadi pintu masuk yang tipis.

Contoh boundary yang sehat di monolith

Walaupun tetap monolith, susun kode berdasarkan domain, bukan berdasarkan framework semata.

src/
  app/
    api/
      orders/route.ts
  modules/
    orders/
      application/
      domain/
      infrastructure/
    billing/
      application/
      domain/
      infrastructure/
  lib/
    db/
    cache/
    auth/

Dengan struktur seperti ini, Anda bisa menjaga agar route hanya memanggil use case, bukan berisi seluruh logika bisnis.

// app/api/orders/route.ts
import { createOrder } from '@/modules/orders/application/create-order'

export async function POST(req: Request) {
  const body = await req.json()
  const result = await createOrder(body)
  return Response.json(result, { status: 201 })
}

Manfaatnya: ketika nanti perlu diekstrak menjadi service terpisah, logika domain tidak tertanam di layer HTTP Next.js.

Database: satu database bukan dosa, tapi pahami batasnya

Banyak tim terlalu cepat memisahkan service tetapi tetap berbagi satu database. Ini sering menciptakan boundary palsu. Jika service masih saling mengakses tabel yang sama secara bebas, Anda belum benar-benar memisahkan tanggung jawab.

Untuk tahap awal, satu database di monolith justru sangat masuk akal. Baru ketika domain sudah stabil dan kebutuhan isolasi kuat, Anda bisa mempertimbangkan pemisahan akses data per domain atau bahkan datastore terpisah. Tetapi lakukan ini hati-hati karena konsekuensinya besar: transaksi lintas domain jadi lebih rumit, reporting bisa berubah, dan debugging consistency menjadi lebih sulit.

Cache: tempat pertama untuk memperpanjang umur monolith

Sebelum memecah arsitektur, cek apakah bottleneck sebenarnya ada di cache strategy. Banyak monolith terasa "tidak scalable" padahal masalahnya adalah:

• query database tidak efisien
• tidak ada caching untuk data read-heavy
• revalidasi terlalu agresif
• tidak ada deduplikasi request ke layanan internal

Perbaikan cache sering memberi hasil besar tanpa menambah kompleksitas organisasi. Anda bisa menerapkan cache pada hasil query, response integrasi eksternal, atau data agregasi yang mahal dihitung ulang.

Background job: kandidat paling sering dipisah lebih dulu

Jika Anda perlu memproses pekerjaan di luar request web, pendekatan bertahap yang realistis adalah:

1. Next.js menerima request dan menulis data inti ke database
2. aplikasi mendorong event atau enqueue job
3. worker terpisah memproses pekerjaan asinkron

Ini memberi manfaat besar tanpa harus memecah seluruh backend. Jalur request pengguna tetap sederhana, sementara proses berat dipindahkan ke worker yang bisa di-scale sendiri.

// pseudo-code dalam route handler
import { saveOrder } from '@/modules/orders/application/save-order'
import { enqueueJob } from '@/lib/queue'

export async function POST(req: Request) {
  const payload = await req.json()
  const order = await saveOrder(payload)

  await enqueueJob('order.confirmation', {
    orderId: order.id,
  })

  return Response.json({ id: order.id }, { status: 201 })
}

Pola ini bekerja karena request user selesai cepat, sedangkan email, sinkronisasi, atau invoice generation dijalankan di luar jalur kritis.

Biaya operasional yang sering diremehkan saat memecah service

1. Observability lintas service

Begitu request melewati lebih dari satu service, Anda butuh minimal:

• request ID atau correlation ID
• centralized logging
• metrics per service
• distributed tracing jika alur sudah kompleks
• alerting yang tidak bising

Tanpa itu, debugging insiden akan lambat. Gejala umum: frontend timeout, service A bilang sukses, service B tidak menerima payload, dan tidak ada jejak yang bisa dirangkai cepat.

2. Auth dan security antar-service

Di monolith, pengecekan auth biasanya terpusat. Setelah dipecah, Anda harus memikirkan:

• siapa yang boleh memanggil service tertentu
• bagaimana menyampaikan identity atau claims
• bagaimana menangani secret rotation
• bagaimana membatasi akses jaringan

Kesalahan umum adalah memakai token statis jangka panjang untuk semua komunikasi internal tanpa audit yang memadai.

3. Contract dan compatibility

Service terpisah berarti ada kontrak API. Perubahan payload yang tampak kecil bisa mematahkan konsumen lain. Karena itu, Anda perlu disiplin soal versioning, backward compatibility, atau setidaknya contract testing.

4. Retries, timeouts, dan idempotency

Network call bisa gagal sebagian. Saat user klik sekali, bisa jadi service menerima request dua kali akibat retry. Sistem yang dipecah perlu memikirkan idempotency sejak awal, terutama untuk pembayaran, pembuatan order, dan pengiriman notifikasi.

5. Biaya manusia

Service bukan hanya biaya server. Ada biaya koordinasi, on-call, dokumentasi, runbook, dan ownership. Untuk tim kecil, ini sering lebih mahal daripada beban teknis yang ingin diselesaikan.

Checklist keputusan: tetap monolith atau mulai pecah?

Gunakan checklist ini secara jujur. Jika sebagian besar jawabannya masih di kolom kiri, jangan terburu-buru memecah.

Tetap monolith jika:

• tim masih kecil dan ownership belum terbagi jelas
• sebagian besar fitur masih berubah cepat
• bottleneck utama masih bisa diselesaikan dengan query tuning, cache, atau worker
• observability lintas service belum siap
• deploy satu aplikasi masih dapat diterima
• domain belum cukup stabil untuk dibuat boundary API yang tahan lama

Mulai pecah jika:

• ada workload yang butuh scaling berbeda
• background processing sudah dominan dan kritikal
• integrasi vendor/internal sangat kompleks dan mengotori domain utama
• tim/domain ownership sudah jelas
• release cadence antar-area berbeda jauh
• insiden sering terjadi karena semua beban terkunci dalam satu jalur aplikasi

Anti-pattern umum

1. Memecah karena terdengar lebih modern

Ini alasan yang buruk. Service harus menyelesaikan masalah konkret, bukan sekadar mengikuti gaya arsitektur.

2. Memecah tanpa boundary domain yang jelas

Jika billing, orders, dan users masih saling membaca tabel yang sama tanpa aturan, Anda hanya memindahkan kompleksitas, bukan menguranginya.

3. Menaruh logika domain besar di Route Handler

Ini membuat Next.js layer HTTP menjadi terlalu gemuk dan sulit diekstrak. Pisahkan logika aplikasi/domain dari transport layer sedini mungkin.

4. Menjalankan pekerjaan panjang di request path

Contohnya generate laporan besar, sinkronisasi vendor, atau upload processing langsung saat request user menunggu. Ini merusak latency dan reliability. Gunakan queue/worker.

5. Memecah semua hal sekaligus

Strategi yang lebih aman adalah memecah area dengan return tertinggi lebih dulu, biasanya background worker atau modul integrasi. Tidak perlu langsung membuat banyak service.

6. Menganggap shared database sebagai solusi permanen

Shared database bisa dipakai sebagai tahap transisi, tetapi bila dibiarkan terlalu lama tanpa aturan ownership data, coupling tetap tinggi dan batas arsitektur menjadi kabur.

Rekomendasi migrasi bertahap yang realistis

Tahap 1: Rapikan monolith dulu

Sebelum mengekstrak apa pun:

• pisahkan modul berdasarkan domain
• buat service layer/application layer yang dipanggil oleh route
• kurangi query dan dependency lintas domain
• standarkan logging dan error handling
• identifikasi jalur yang read-heavy dan write-heavy

Kalau monolith belum rapi, service yang lahir dari situ biasanya hanya membawa kekacauan ke unit yang lebih kecil.

Tahap 2: Keluarkan background job terlebih dahulu

Ini langkah dengan rasio manfaat terhadap risiko yang sering paling baik. Anda tetap mempertahankan Next.js sebagai UI + BFF, tetapi memindahkan pekerjaan asinkron ke worker terpisah. Dampaknya:

• latency request turun
• retry lebih terkontrol
• scaling lebih fleksibel
• insiden dari job berat tidak langsung menjatuhkan jalur user-facing

Tahap 3: Ekstrak modul integrasi yang paling berisik

Pilih modul yang:

• sering timeout
• bergantung pada banyak vendor
• punya retry dan mapping payload kompleks
• tidak perlu sinkron langsung dengan render halaman

Ini cocok menjadi service integrasi atau adapter layer terpisah.

Tahap 4: Pisahkan domain yang benar-benar punya ownership sendiri

Contoh realistis: billing atau fulfillment. Jangan mulai dari domain yang batasnya masih kabur atau sering berubah.

Tahap 5: Perkuat observability sebelum menambah service lagi

Setelah satu atau dua service muncul, berhenti sejenak dan evaluasi:

• apakah tracing antar-service jelas
• apakah on-call lebih berat
• apakah deploy lebih aman atau justru lebih rumit
• apakah contract change terkendali

Kalau fondasi operasional belum matang, menambah service berikutnya biasanya memperbesar kebingungan.

Contoh keputusan untuk tim kecil hingga menengah

Tim kecil, satu produk, satu database, fitur masih berubah cepat

Rekomendasi: tetap di Next.js monolith. Rapikan boundary internal, gunakan cache dengan baik, dan keluarkan background job ke worker jika mulai berat.

Tim menengah, ada admin internal, dashboard pelanggan, webhook, dan sinkronisasi vendor

Rekomendasi: pertahankan Next.js sebagai web app + BFF, tetapi pisahkan worker/job processor dan service integrasi bila memang noisy. Belum perlu memecah semua domain bisnis.

Beberapa tim dengan ownership domain berbeda

Rekomendasi: mulai ekstrak domain yang stabil dan punya lifecycle rilis berbeda, misalnya billing atau fulfillment. Pastikan kontrak API, auth internal, logging, dan metrics sudah siap.

Debugging tips saat arsitektur mulai menegang

• Jika request lambat, cek dulu query database dan cache hit ratio sebelum menyalahkan monolith.
• Jika timeout sering terjadi saat integrasi vendor, pindahkan ke jalur async lebih dulu, bukan langsung memecah seluruh backend.
• Jika deploy menakutkan karena efek samping lintas modul, ukur dependency internal dan rapikan modularitas sebelum ekstraksi.
• Jika satu fitur perlu data dari banyak domain, waspadai boundary yang salah. Memecah terlalu dini bisa memperparah kebutuhan agregasi lintas service.
• Jika error sulit ditelusuri setelah ada dua atau tiga service, prioritaskan correlation ID dan struktur logging yang konsisten.

Kesimpulan

Keputusan antara Next.js monolith dan service terpisah bukan soal mana yang lebih canggih, tetapi mana yang paling sesuai dengan bentuk masalah Anda saat ini. Untuk banyak tim, monolith masih tepat lebih lama daripada yang sering diasumsikan, terutama jika struktur internal rapi, cache benar, dan background job dipisahkan secara terbatas.

Mulailah memecah ketika ada sinyal kuat: scaling bottleneck yang berbeda, background processing yang kritikal, integrasi yang makin bising, release cadence yang bertabrakan, atau ownership domain yang benar-benar terpisah. Dan yang paling penting, lakukan secara bertahap. Sering kali evolusi terbaik bukan dari monolith langsung ke microservices, melainkan dari monolith yang sehat ke modular monolith, lalu ke service terpisah secara selektif.