Banyak app hasil AI atau vibe-coded app bisa berjalan cepat: endpoint hidup, UI tampil, database tersambung, bahkan fitur utama terlihat selesai. Masalahnya, aplikasi yang works belum tentu mudah dioperasikan, dites, di-scale, atau dipelihara. Setelah fase “berhasil jalan”, keputusan penting berikutnya adalah: tetap sebagai monolit modular, dipisah ke worker, atau mulai ke microservice dini?

Jawaban singkatnya: untuk sebagian besar tim kecil dan produk yang masih mencari bentuk, monolit modular adalah default yang paling aman. Jika ada pekerjaan berat atau lambat seperti kirim email, generate laporan, sinkronisasi pihak ketiga, atau proses AI inference yang tidak perlu sinkron, pisahkan dulu ke worker. Microservice baru masuk akal jika ada batas domain yang jelas, kebutuhan deployment terpisah, pola scaling yang berbeda, atau kebutuhan isolasi kegagalan yang memang nyata—bukan sekadar karena aplikasi mulai terasa ramai.

Mengapa app hasil AI perlu dinilai ulang sebelum arsitekturnya dipecah?

Kode yang dihasilkan AI sering punya pola yang terlihat rapi di permukaan, tetapi menyimpan masalah struktural:

  • Boundary domain kabur: logika user, billing, notifikasi, dan admin bercampur di handler yang sama.
  • Duplikasi tinggi: validasi, query, dan transformasi data diulang di banyak tempat.
  • Coupling tak terlihat: satu perubahan kecil memicu efek samping di endpoint lain.
  • Abstraksi prematur: ada banyak lapisan helper/service, tetapi tidak jelas siapa yang memiliki aturan bisnis.
  • Error handling tidak konsisten: retry, timeout, dan logging tidak seragam.

Jika struktur internalnya belum sehat, memecahnya menjadi microservice sering hanya memindahkan kekacauan ke jaringan. Masalah yang tadinya berupa pemanggilan fungsi lokal berubah menjadi koordinasi API, retry, observability, autentikasi service-to-service, dan konsistensi data.

Prinsip praktis: jangan jadikan microservice sebagai cara “merapikan” kode AI-generated. Rapikan boundary, dependency, dan alur data di dalam monolit lebih dulu. Jika nanti perlu dipisah, ekstraksinya jauh lebih aman.

Opsi 1: Monolit modular sebagai pilihan default

Monolit modular berarti aplikasi tetap dideploy sebagai satu unit, tetapi kode dipecah dengan batas modul yang jelas. Ini berbeda dari monolit berantakan. Tujuannya bukan sekadar memisah folder, tetapi membatasi dependensi dan tanggung jawab.

Kapan monolit modular paling cocok?

  • Tim kecil, misalnya 2–8 engineer.
  • Produk masih sering berubah dan prioritas bisnis belum stabil.
  • Skala trafik belum menuntut scaling per domain yang berbeda.
  • Sebagian besar operasi masih nyaman dilakukan dalam satu transaksi database.
  • Biaya operasional perlu dijaga rendah.

Kelebihan teknis monolit modular

  • Deployment sederhana: satu artefak, satu pipeline utama, lebih sedikit moving parts.
  • Testing lebih mudah: integration test bisa langsung memverifikasi alur lintas modul tanpa jaringan.
  • Observability lebih sederhana: log, trace, dan metric berada dalam satu proses atau satu aplikasi.
  • Konsistensi data lebih mudah: transaksi lintas tabel lebih langsung daripada koordinasi antarservice.
  • Refactor lebih murah: memindahkan kode antar modul tidak perlu perubahan kontrak API publik.

Risiko jika tidak dijaga dengan disiplin

  • Semua modul bisa saling mengakses database secara bebas.
  • Perubahan kecil memicu redeploy seluruh aplikasi.
  • Hot path dan background task bersaing memperebutkan resource yang sama.
  • Ukuran codebase tumbuh cepat dan sulit dipahami, apalagi jika banyak bagian ditulis AI.

Pola struktur yang layak dipakai

Contoh struktur monolit modular untuk backend web:

src/
  modules/
    auth/
      application/
      domain/
      infrastructure/
      api/
    billing/
      application/
      domain/
      infrastructure/
      api/
    notifications/
      application/
      domain/
      infrastructure/
      api/
  shared/
    db/
    logging/
    queue/
    http/

Yang penting bukan nama foldernya, tetapi aturan dependensinya:

  • Domain tidak tahu detail HTTP, ORM, atau queue.
  • Application mengorkestrasi use case, bukan menyimpan logika transport.
  • Infrastructure menangani database, cache, broker, email provider, dan API eksternal.
  • API hanya adapter masuk: controller, route, serializer, auth middleware.

Jika app hasil AI belum sampai tahap ini, biasanya terlalu dini membahas microservice.

Opsi 2: Pisahkan ke worker sebelum microservice

Banyak masalah performa dan keandalan bukan karena aplikasi perlu microservice, melainkan karena ada pekerjaan yang tidak cocok dijalankan sinkron di request utama. Di sinilah worker sering menjadi langkah refactor paling bernilai.

Contoh pekerjaan yang cocok dipindah ke worker

  • Kirim email, SMS, dan push notification.
  • Generate PDF, invoice, thumbnail, atau ekspor CSV.
  • Sinkronisasi data ke layanan pihak ketiga.
  • Rekalkulasi statistik atau agregasi laporan.
  • Proses AI yang lambat dan tidak perlu hasil instan bagi user.

Mengapa worker sering cukup?

Dengan queue dan worker, Anda tetap menjaga satu codebase utama, tetapi memisahkan execution model. Request web tetap responsif, beban CPU atau I/O berat dipindah ke proses background, dan scaling bisa dilakukan spesifik pada worker tanpa memecah domain menjadi service mandiri.

Contoh alur sederhana

  1. User membuat pesanan.
  2. Aplikasi menyimpan order dan commit transaksi.
  3. Aplikasi menerbitkan job SendOrderConfirmation dan GenerateInvoicePdf.
  4. Worker memproses job secara asynchronous.
// Pseudocode
function createOrder(request) {
  const order = orderService.create(request.payload);

  queue.publish("SendOrderConfirmation", { orderId: order.id });
  queue.publish("GenerateInvoicePdf", { orderId: order.id });

  return { orderId: order.id, status: "created" };
}

Perubahan ini sering memberi dampak besar pada latency tanpa menambah kompleksitas operasional sebesar microservice.

Trade-off worker yang perlu dipahami

  • Eventually consistent: hasil pekerjaan background tidak langsung tersedia.
  • Perlu idempotency: job bisa diproses ulang saat retry.
  • Butuh observability queue: antrean macet, retry loop, dan dead-letter queue harus terlihat.
  • Error handling berubah: exception tidak lagi terlihat langsung di response HTTP.

Worker adalah pilihan kuat ketika masalah utama Anda adalah latency, throughput background task, atau isolasi resource, tetapi batas domain bisnisnya belum pantas dijadikan service sendiri.

Opsi 3: Kapan microservice dini memang masuk akal?

Microservice dini bukan otomatis salah. Ia tepat jika ada kebutuhan nyata yang sulit dipenuhi oleh monolit modular plus worker.

Sinyal teknis yang valid

  • Domain boundary jelas dan stabil: misalnya billing, identity, atau ingestion pipeline punya aturan bisnis yang cukup mandiri.
  • Kebutuhan deployment terpisah: satu area berubah sering dan harus dirilis tanpa menyentuh area lain.
  • Pola scaling sangat berbeda: misalnya API utama ringan, tetapi layanan pemrosesan dokumen sangat CPU-intensive.
  • Failure isolation penting: kegagalan modul tertentu tidak boleh mengganggu alur inti.
  • Perbedaan kebutuhan keamanan atau kepatuhan: data sensitif mungkin perlu kontrol akses, audit, atau network boundary yang lebih ketat.
  • Integrasi organisasi: beberapa tim benar-benar bekerja otonom dengan ownership yang jelas.

Biaya tersembunyi microservice

  • Observability jauh lebih berat: butuh tracing lintas service, correlation ID, metric per service, dan log aggregation yang rapi.
  • Testing berubah bentuk: unit test lokal tidak cukup; perlu contract test, integration environment, dan verifikasi backward compatibility.
  • Debugging lebih sulit: bug bisa muncul dari timeout, retry, schema mismatch, atau antrian event.
  • Data consistency lebih rumit: transaksi lintas service tidak lagi sederhana. Sering perlu outbox pattern, saga, atau kompensasi.
  • Operasional bertambah: CI/CD, secret management, service discovery, rate limiting, auth antarservice, dan rollback harus dipikirkan untuk banyak unit.

Untuk tim kecil, biaya ini sering lebih besar daripada manfaatnya, terutama jika kode dasar hasil AI sendiri belum cukup terstruktur.

Trade-off utama: monolit modular vs worker vs microservice

1. Coupling

Monolit modular masih memungkinkan coupling tinggi jika tidak dijaga. Namun coupling lebih mudah ditemukan lewat review kode dan refactor internal. Worker mengurangi coupling waktu eksekusi, tetapi biasanya masih berada dalam codebase dan model data yang sama. Microservice memaksa boundary lewat API, tetapi juga berisiko menghasilkan coupling baru pada kontrak jaringan, skema event, dan asumsi retry.

2. Deployment

Monolit modular paling sederhana: satu deployable unit. Worker menambah satu atau lebih proses deploy, tetapi biasanya masih memakai repositori dan pipeline yang sama. Microservice memberi deployment independen, tetapi menambah koordinasi rilis dan manajemen kompatibilitas antarlayanan.

3. Observability

Pada monolit modular, request path cenderung lebih mudah dilacak. Pada arsitektur dengan worker, Anda perlu melacak hubungan antara request awal dan job asynchronous. Pada microservice, distributed tracing hampir wajib jika ingin debugging tetap waras.

4. Testing

Monolit modular unggul pada integration test lokal. Worker menambah kebutuhan test retry, idempotency, dan antrian. Microservice membutuhkan kombinasi unit test, contract test, integration test, dan sering kali test environment yang lebih realistis.

5. Performa dan scaling

Monolit modular sering cukup cepat karena komunikasi antarmodul adalah panggilan lokal, bukan jaringan. Worker efektif untuk memisahkan beban asynchronous. Microservice berguna jika service tertentu memang butuh pola scaling sendiri, tetapi komunikasi jaringan, serialisasi, dan latency antarservice adalah biaya nyata.

6. Failure isolation

Monolit modular cenderung berbagi proses dan resource, sehingga kebocoran memori atau CPU spike bisa berdampak luas. Worker sudah memberi isolasi lebih baik untuk background task. Microservice memberi isolasi paling kuat, tetapi hanya efektif jika timeout, circuit breaker, dan fallback dirancang dengan benar.

7. Biaya operasional

Biaya bukan hanya cloud bill. Yang sering lebih mahal adalah waktu engineer: setup pipeline, dashboard, alarm, on-call, incident response, dan investigasi bug lintas service. Tim kecil sering mendapat ROI terbaik dari monolit modular plus worker, bukan dari pemecahan service terlalu dini.

Dampak khusus pada kode AI-generated

Kode hasil AI punya karakter yang membuat keputusan arsitektur lebih sensitif:

  • Inkonistensi pola: dua modul serupa bisa memakai pendekatan berbeda.
  • Boundary palsu: ada class/service banyak, tetapi sebenarnya hanya wrapper tipis tanpa pemisahan tanggung jawab.
  • Query dan side effect tersembunyi: satu method tampak sederhana, tetapi diam-diam mengakses database, cache, dan HTTP eksternal sekaligus.
  • Test coverage menipu: banyak test happy path, sedikit verifikasi pada kegagalan, race condition, atau retry.

Karena itu, sebelum memecah ke microservice, lakukan audit kecil:

  • Petakan use case utama dan dependency tiap modul.
  • Catat akses database lintas domain.
  • Identifikasi bagian yang punya efek samping eksternal.
  • Periksa apakah naming dan tanggung jawab konsisten.
  • Tambahkan observability minimum: structured log, metric request/job, dan correlation ID.

Checklist keputusan arsitektur

Gunakan checklist ini setelah aplikasi buatan AI sudah berjalan dan mulai dipakai.

Tetap di monolit modular jika:

  • Satu database transaksi masih menjadi pusat kebenaran utama.
  • Mayoritas perubahan fitur menyentuh beberapa domain sekaligus.
  • Tim belum punya kapasitas operasional untuk banyak service.
  • Masalah utama adalah struktur kode, bukan batas deploy.
  • Latency utama masih berasal dari query, N+1, cache miss, atau I/O sinkron yang bisa diperbaiki tanpa split service.

Pisah ke worker jika:

  • Response API lambat karena pekerjaan non-kritis dijalankan sinkron.
  • Ada tugas berat, bursty, atau mudah di-retry.
  • Anda butuh scaling berbeda antara web process dan background process.
  • Masalah utama adalah throughput background job, bukan domain ownership.

Mulai pertimbangkan microservice jika:

  • Ada modul dengan traffic, resource profile, atau kebutuhan rilis yang benar-benar berbeda.
  • Kontrak domain sudah jelas dan relatif stabil.
  • Tim siap mengelola tracing, retry, timeout, auth antarservice, dan compatibility contract.
  • Incident pada satu domain harus bisa diisolasi tanpa menjatuhkan domain lain.
  • Refactor internal dalam monolit sudah dilakukan, tetapi bottleneck organisasi atau operasional tetap ada.

Sinyal bahwa refactor sudah perlu dilakukan

  • Satu endpoint memanggil terlalu banyak dependency: database, cache, provider eksternal, lalu memicu side effect tambahan.
  • Waktu deploy makin menegangkan: perubahan kecil berisiko merusak area yang tidak terkait.
  • Queue mulai campur aduk: job ringan dan job berat berada di jalur yang sama sehingga saling menghambat.
  • Modul tertentu butuh scaling sendiri: misalnya proses dokumen atau image processing mengganggu web API.
  • Debugging butuh membaca banyak file tidak terkait: sinyal coupling berlebih dan boundary lemah.
  • Insiden berulang berasal dari dependensi eksternal yang tidak diisolasi.

Contoh skenario backend web nyata

Skenario 1: SaaS internal dengan auth, billing, dan notifikasi

Sebuah SaaS internal punya modul login, manajemen user, subscription, invoice, dan notifikasi email. Trafik belum tinggi, tim hanya 4 engineer. AI membantu menghasilkan banyak CRUD dan admin panel.

Keputusan yang masuk akal: tetap di monolit modular. Billing dan auth sangat terhubung dengan alur user. Invoice PDF dan email dipindahkan ke worker. Alasan utamanya: transaksi masih nyaman dalam satu database, tim kecil, dan perubahan produk masih sering memotong banyak modul sekaligus.

Skenario 2: Marketplace dengan proses impor katalog besar

Marketplace memiliki API utama untuk buyer dan seller, tetapi juga fitur impor katalog dari supplier yang dapat memproses file besar, normalisasi data, dan validasi bertingkat.

Keputusan yang masuk akal: tetap monolit modular untuk domain transaksi utama, tetapi buat worker pipeline terpisah untuk impor. Jika nanti impor katalog berkembang menjadi sistem ingestion mandiri dengan pola scaling, storage, dan monitoring yang sangat berbeda, barulah ekstraksi ke service khusus menjadi rasional.

Skenario 3: Platform yang bergantung pada provider eksternal yang sering timeout

Aplikasi melakukan sinkronisasi order ke beberapa provider. Kegagalan provider tidak boleh mengganggu checkout utama.

Keputusan yang masuk akal: pindahkan integrasi ke worker atau service integrasi terpisah, tergantung tingkat isolasi yang dibutuhkan. Jika sinkronisasi hanya background task, worker cukup. Jika provider handling sudah menjadi domain kompleks sendiri—dengan retry policy, audit, reconciliation, dan scaling berbeda—service terpisah mulai masuk akal.

Panduan implementasi agar transisi tidak menyakitkan

1. Rapikan boundary sebelum split

Pastikan modul punya API internal yang jelas. Jangan biarkan kode luar mengakses tabel atau repository modul lain secara bebas. Jika boundary internal lemah, split eksternal akan mahal.

2. Tambahkan observability sejak di monolit

Gunakan structured logging, correlation ID, dan metric untuk request serta job queue. Ini penting agar saat pindah ke worker atau microservice, pola observability tidak dimulai dari nol.

3. Terapkan idempotency pada job

Job background harus aman diulang. Simpan status eksekusi, gunakan unique key bila perlu, dan hindari side effect ganda seperti email terkirim dua kali atau invoice dibuat berulang.

4. Pisahkan scaling sebelum memisahkan repositori

Sering kali Anda belum perlu repositori atau service terpisah. Menjalankan web process dan worker process secara independen sudah cukup memberi manfaat scaling yang besar.

5. Gunakan ekstraksi bertahap

Jika akhirnya menuju microservice, mulai dari domain yang paling jelas batasnya dan paling sedikit dependensi sinkronnya. Hindari memecah modul yang masih sering berubah definisinya.

Kesalahan umum yang perlu dihindari

  • Memecah service berdasarkan folder, bukan berdasarkan boundary bisnis.
  • Menganggap performa otomatis membaik setelah microservice. Sering kali justru menambah latency jaringan.
  • Membuat worker tanpa strategi retry dan dead-letter handling.
  • Tidak mengukur bottleneck nyata: CPU, I/O, query lambat, lock database, atau dependency eksternal.
  • Mengandalkan kode AI-generated tanpa review ownership: siapa pemilik aturan bisnis, siapa yang bertanggung jawab atas error path, dan bagian mana yang aman untuk diekstrak.

Penutup

Menilai app hasil AI bukan soal apakah ia bisa jalan, tetapi apakah ia bisa bertahan saat fitur bertambah, trafik naik, dan tim harus memperbaiki bug di bawah tekanan. Untuk kebanyakan kasus, monolit modular adalah titik awal terbaik. Saat kebutuhan asynchronous muncul, pisahkan ke worker. Baru ketika ada batas domain, deployment, scaling, dan failure isolation yang benar-benar nyata, microservice menjadi keputusan teknis yang masuk akal.

Jika Anda sedang mengevaluasi aplikasi buatan AI yang sudah hidup di production atau mendekati production, pertanyaan terbaik bukan “arsitektur mana yang paling keren?”, melainkan: masalah operasional apa yang sedang kita hadapi sekarang, dan solusi paling kecil apa yang benar-benar menyelesaikannya?