Jika tim Anda sedang mengejar peluang AI seperti build week, fellowship, residency, atau program pembelajaran intensif, pertanyaan arsitektur yang paling relevan biasanya bukan “apakah kita butuh microservices?”, melainkan bagaimana meminimalkan friksi agar eksperimen bisa dikirim cepat tanpa membuat sistem berantakan setelah 1-3 bulan.

Dalam banyak kasus, jawaban praktisnya adalah memulai dengan monolit modular: satu codebase, satu pipeline deploy, satu boundary operasional, tetapi dengan pemisahan modul yang jelas untuk domain seperti auth, billing, ingestion, orchestration, retrieval, dan observability. Pendekatan ini memberi kecepatan lebih tinggi dibanding microservices awal, sambil tetap menyediakan jalur migrasi saat beban, batas tim, atau reliabilitas sudah menuntut pemisahan service.

Artikel ini membahas trade-off nyata antara monolit modular dan microservices awal untuk produk AI, termasuk dampaknya terhadap kecepatan delivery, biaya cloud, observability, deployment, batas tim, reliabilitas, dan maintainability. Fokusnya bukan teori arsitektur umum, tetapi keputusan praktis untuk engineer dan team lead yang harus mengirim MVP dengan cepat tanpa mengambil utang teknis yang tidak perlu.

Kenapa konteks peluang AI mengubah prioritas arsitektur

Produk AI yang dibangun untuk mengejar peluang seperti hack-style sprint, build week, fellowship, atau residency biasanya memiliki karakteristik yang berbeda dari sistem enterprise yang stabil:

  • Ruang masalah belum final. Anda mungkin masih mencari use case yang benar-benar bernilai.
  • Alur aplikasi sering berubah. Prompt, retrieval flow, data source, evaluasi, dan UX bisa berubah beberapa kali dalam seminggu.
  • Beban traffic awal belum pasti. Yang lebih penting adalah kecepatan belajar, bukan optimasi distribusi service.
  • Dependency eksternal tinggi. LLM API, vector database, job queue, object storage, OCR, atau webhook pihak ketiga sering menjadi bottleneck utama, bukan CPU aplikasi Anda.
  • Tim kecil merangkap banyak peran. Satu engineer bisa menyentuh backend, prompt orchestration, data pipeline, dan deployment sekaligus.

Dalam kondisi seperti ini, microservices awal sering gagal bukan karena salah secara konsep, tetapi karena biaya koordinasi-nya terlalu mahal dibanding manfaatnya. Tiap service menambah overhead pada CI/CD, konfigurasi environment, IAM, logging, tracing, retry policy, network debugging, dan on-call complexity.

Monolit modular: pilihan default yang paling sering masuk akal

Monolit modular berarti aplikasi tetap berjalan sebagai satu unit deploy utama, tetapi struktur code dan boundary domain dipisahkan secara tegas. Ini berbeda dari monolit “campur aduk” di mana semua logic saling bergantung tanpa batas yang jelas.

Ciri monolit modular yang sehat

  • Satu repository utama, atau minimal satu deployable utama.
  • Modul domain dipisahkan dengan jelas, misalnya api, workspace, document ingestion, ai orchestration, evaluation, billing, dan admin.
  • Kontrak antar modul eksplisit, misalnya lewat interface internal, event domain, atau command handler.
  • Job yang berat dipindahkan ke worker async, tetapi masih dalam boundary sistem yang sama.
  • Database boleh satu, tetapi skema dan akses tabel dijaga per modul.

Untuk tim kecil yang mengejar peluang AI, ini biasanya memberikan kombinasi terbaik antara kecepatan implementasi dan kemampuan berkembang secara bertahap.

Kenapa monolit modular lebih cepat untuk eksperimen AI

  • Perubahan lintas domain lebih mudah. Saat Anda mengubah flow chat, retrieval, evaluasi, dan billing sekaligus, satu codebase mengurangi friction integrasi.
  • Debugging lebih sederhana. Anda tidak perlu menelusuri error melalui beberapa service, API gateway, retry queue, dan kontrak network.
  • Deploy lebih murah secara operasional. Satu pipeline dan satu environment cenderung lebih mudah dijaga daripada banyak unit deploy.
  • Observability bisa dibangun lebih cepat. Centralized logging, metrics, dan tracing lebih sederhana saat boundary proses belum terlalu banyak.
  • Local development lebih realistis. Engineer bisa menjalankan aplikasi dan worker tanpa menyalakan banyak service terpisah.

Kapan microservices awal justru memperlambat tim

Microservices sering terlihat menarik karena menjanjikan isolasi, scalability, dan ownership tim. Masalahnya, manfaat tersebut biasanya baru terasa setelah ada kompleksitas nyata yang memang perlu dipecah.

Overhead yang sering diremehkan

  • Kontrak API cepat usang. Pada fase eksperimen AI, bentuk request/response sering berubah. Jika tiap perubahan harus melewati contract negotiation antar service, laju eksperimen turun.
  • Latensi jaringan bertambah. Prompt orchestration, retrieval, re-ranking, dan persistence yang dipecah terlalu dini bisa menambah banyak hop internal.
  • Biaya cloud naik diam-diam. Banyak container kecil, load balancer, managed messaging, observability agent, dan storage log dapat menghabiskan anggaran lebih cepat daripada aplikasi itu sendiri.
  • Incident lebih sulit dianalisis. Kegagalan bisa terjadi pada timeout antar service, retry yang berantai, atau message duplication.
  • Testing end-to-end lebih berat. Anda perlu menyiapkan service dependency, mock, contract test, dan seeded data lintas boundary.

Pada produk AI, masalah utama di fase awal sering bukan skalabilitas horizontal aplikasi web, melainkan iterasi produk: bagaimana memperbaiki kualitas jawaban, mengendalikan biaya token, meningkatkan kualitas ingestion, dan menambah alat evaluasi. Arsitektur yang terlalu terdistribusi sering mengambil waktu dari pekerjaan yang lebih bernilai.

Matriks keputusan: monolit modular vs microservices awal

Gunakan matriks berikut sebagai panduan praktis. Ini bukan aturan mutlak, tetapi cukup berguna untuk pengambilan keputusan awal.

Pilih monolit modular jika kondisinya seperti ini

  • Tim kecil: 2-8 engineer, dengan ownership yang masih cair.
  • Produk masih mencari bentuk: use case, model, alur kerja, dan UX belum stabil.
  • Perubahan lintas domain sering: auth, ingestion, retrieval, agent tools, dan UI berubah bersamaan.
  • Traffic masih moderat atau tidak pasti.
  • Satu release train lebih penting daripada deployment independence per domain.
  • Prioritas utama adalah belajar cepat, bukan throughput organisasi yang besar.
  • Biaya cloud perlu dijaga ketat.

Ekstraksi service mulai layak jika muncul sinyal berikut

  • Satu domain memiliki beban komputasi sangat berbeda, misalnya ingestion OCR/transcoding atau batch evaluation yang jauh lebih berat dari web app.
  • Kebutuhan scaling berbeda jelas, misalnya worker ingestion perlu autoscaling agresif sedangkan API utama tidak.
  • Reliabilitas perlu isolasi, contohnya kegagalan pipeline dokumen tidak boleh menjatuhkan experience chat utama.
  • Boundary domain sudah stabil, sehingga kontrak API/internal event tidak berubah tiap minggu.
  • Tim mulai terbelah secara ownership, misalnya ada squad khusus platform ingestion atau evaluation.
  • Siklus deploy perlu dipisah karena frekuensi perubahan atau risiko release antar domain sudah berbeda.
  • Persyaratan keamanan atau compliance berbeda, misalnya pemrosesan data sensitif harus dipisah dari aplikasi umum.

Ringkasan keputusan cepat

  • Default: monolit modular.
  • Tambahkan queue/worker lebih dulu sebelum memecah jadi microservices.
  • Ekstrak service karena kebutuhan yang terukur, bukan karena mengikuti pola arsitektur populer.

Dampak ke kecepatan delivery, biaya, observability, deployment, reliabilitas, dan maintainability

1. Kecepatan delivery

Monolit modular hampir selalu unggul pada fase 0-1, terutama ketika satu fitur menyentuh banyak komponen: upload dokumen, embedding, retrieval, prompt chain, feedback loop, dan analytics. Semua perubahan bisa diuji dalam satu alur lokal atau staging.

Microservices awal bisa berguna jika domain sudah sangat jelas, tetapi pada fase eksperimen sering memperbanyak pekerjaan koordinasi dan integrasi.

2. Biaya cloud

Pada tim awal, biaya cloud sering datang dari tiga sumber: compute idle, egress/networking, dan observability. Microservices menambah ketiganya lebih cepat. Banyak service kecil berarti lebih banyak container yang hidup, log yang tersebar, trace lebih banyak, dan biasanya lebih banyak komponen managed.

Monolit modular dengan worker async memungkinkan Anda memusatkan biaya pada bagian yang benar-benar berat. Misalnya, API utama tetap kecil, sementara ingestion worker diskalakan sesuai antrean.

3. Observability

Produk AI membutuhkan observability yang sedikit berbeda dari aplikasi CRUD biasa. Anda perlu melacak:

  • latensi end-to-end per request,
  • biaya per flow atau per tenant,
  • success/failure per tool call,
  • retrieval hit rate atau kualitas konteks,
  • error eksternal dari model provider, storage, atau vector database.

Dalam monolit modular, korelasi request dan job lebih mudah dibangun sejak awal. Pada microservices, Anda harus menegakkan trace propagation dan correlation ID dengan disiplin tinggi, jika tidak incident akan sulit ditelusuri.

4. Deployment

Satu deployable utama menurunkan beban operasional: lebih sedikit pipeline, lebih sedikit secret management terpisah, dan lebih sedikit konfigurasi rollout. Untuk build week atau program residensi, ini sering berarti perbedaan antara “fitur sempat dikirim” dan “fitur tertahan di plumbing”.

Namun, deployment tunggal bukan berarti semua harus restart bersama selamanya. Anda tetap bisa memisahkan worker atau cron pipeline sebagai unit runtime yang berbeda sambil menjaga satu codebase dan satu model ownership.

5. Batas tim

Microservices baru terasa efektif jika memang ada batas tim yang nyata. Jika tiga engineer yang sama masih mengubah semua domain, pemisahan service hanya memindahkan kompleksitas dari code ke infrastruktur.

Monolit modular lebih cocok saat ownership masih evolving. Boundary tetap dibangun di tingkat modul, dan service extraction bisa mengikuti struktur organisasi saat memang diperlukan.

6. Reliabilitas

Banyak tim mengira microservices otomatis lebih andal. Ini tidak selalu benar. Reliabilitas meningkat hanya jika service dipisah dengan batas kegagalan yang masuk akal. Jika tidak, Anda hanya memindahkan kegagalan dari in-process exception menjadi network failure, timeout, retry storm, atau event duplication.

Pada fase awal, langkah yang sering lebih efektif adalah:

  • membuat operasi berat menjadi async,
  • menambahkan idempotency,
  • menerapkan timeout dan retry yang masuk akal,
  • membatasi concurrency ke dependency mahal,
  • memakai dead-letter queue untuk job gagal.

7. Maintainability

Maintainability bukan hanya soal ukuran codebase. Yang lebih penting adalah arah dependensi, kualitas boundary domain, testability, dan konsistensi pola internal. Monolit modular yang disiplin jauh lebih mudah dirawat daripada microservices yang kontraknya kabur dan observability-nya lemah.

Struktur monolit modular yang cocok untuk produk AI

Contoh struktur berikut cukup realistis untuk MVP AI yang ingin berkembang tanpa buru-buru menjadi distributed system:

src/
  modules/
    auth/
    workspace/
    documents/
    ingestion/
    retrieval/
    ai_orchestration/
    evaluation/
    billing/
    admin/
  shared/
    db/
    queue/
    observability/
    storage/
    llm/
    security/
  app/
    api/
    workers/
    cron/

Prinsip pentingnya:

  • Domain logic tidak langsung tersebar di controller.
  • Integrasi LLM, vector DB, storage, dan queue dibungkus adapter, agar mudah diganti.
  • Operasi berat keluar dari request path dan masuk worker.
  • Modul memiliki interface internal yang jelas.

Contoh alur request yang sehat

  1. User mengunggah dokumen.
  2. API menyimpan metadata, file, dan membuat job ingestion.
  3. Worker ingestion melakukan parsing, chunking, embedding, lalu menyimpan indeks retrieval.
  4. Chat request memakai retrieval module untuk mengambil konteks.
  5. AI orchestration memanggil model provider dan menyimpan jejak observability.

Model ini tetap monolit modular, meski runtime-nya terdiri dari API process dan worker process yang berbeda.

Contoh implementasi praktis: observability dan boundary async

Snippet berikut bukan bergantung pada framework tertentu, tetapi menunjukkan pola yang penting untuk sistem AI awal: correlation ID, pencatatan durasi, dan pemindahan pekerjaan berat ke queue.

// pseudo-code
async function uploadDocument(req, res) {
  const requestId = req.headers['x-request-id'] || generateId();
  const userId = req.auth.userId;

  const doc = await documents.create({
    userId,
    filename: req.file.originalName,
    status: 'queued'
  });

  await storage.put(doc.id, req.file.buffer);

  await queue.publish('document.ingest', {
    requestId,
    documentId: doc.id,
    userId
  });

  logger.info({ requestId, documentId: doc.id }, 'document queued');
  res.status(202).json({ id: doc.id, status: 'queued' });
}

async function ingestDocumentJob(msg) {
  const start = Date.now();
  const { requestId, documentId, userId } = msg;

  try {
    const file = await storage.get(documentId);
    const chunks = await ingestion.parseAndChunk(file);
    const embeddings = await llm.embedMany(chunks);
    await retrievalIndex.upsert(documentId, chunks, embeddings);
    await documents.markReady(documentId);

    metrics.timing('ingestion.duration_ms', Date.now() - start, { status: 'ok' });
    logger.info({ requestId, documentId, userId }, 'ingestion completed');
  } catch (err) {
    await documents.markFailed(documentId, sanitizeError(err));
    metrics.increment('ingestion.failed');
    logger.error({ requestId, documentId, err }, 'ingestion failed');
    throw err;
  }
}

Pola ini bekerja baik dalam monolit modular karena:

  • request web tidak menunggu pekerjaan berat selesai,
  • trace antar API dan worker masih bisa dikorelasikan,
  • worker bisa diskalakan terpisah tanpa memecah codebase menjadi banyak service.

Kapan tetap monolit, kapan ekstraksi service layak

Tetap monolit modular jika

  • Fitur inti masih berubah cepat setiap minggu.
  • Mayoritas bug masih terkait logic produk, bukan bottleneck runtime terisolasi.
  • Engineer sering perlu mengubah lebih dari satu domain sekaligus.
  • Biaya dan kompleksitas ops masih lebih penting daripada deployment independence.
  • Belum ada metrik yang menunjukkan satu modul benar-benar mendominasi beban.

Ekstraksi service layak jika

  • Ingestion pipeline perlu skala, library, atau resource profile yang berbeda jauh dari API utama.
  • Evaluation/batch scoring berjalan terjadwal, panjang, dan memerlukan antrean serta retry policy sendiri.
  • Realtime chat API butuh reliabilitas tinggi dan harus terlindung dari kegagalan batch atau ingestion.
  • Tenant enterprise menuntut isolasi keamanan atau jaringan tertentu.
  • Tim platform/internal tooling mulai muncul dengan ownership jelas.

Ekstraksi pertama yang paling sering masuk akal dalam produk AI biasanya bukan memecah semuanya menjadi banyak service kecil, tetapi memisahkan workload yang karakteristik operasionalnya benar-benar berbeda: misalnya ingestion worker, evaluation runner, atau webhook processor.

Anti-pattern umum yang perlu dihindari

1. Memulai dengan microservices karena “nanti pasti scale”

Skalabilitas tanpa validasi produk sering menghasilkan sistem mahal yang belum tentu dipakai. Scale yang paling mendesak di awal biasanya adalah scale pembelajaran.

2. Monolit tanpa boundary

Masalah bukan pada monolitnya, tetapi pada code yang tidak modular. Jika semua modul saling mengakses tabel, helper, dan adapter tanpa aturan, Anda akan kesulitan mengekstrak apa pun nanti.

3. Sinkronisasi berlebihan di request path

Jangan lakukan OCR, parsing besar, embedding massal, atau evaluasi panjang langsung di endpoint user-facing jika bisa diantrekan. Ini cepat menurunkan reliabilitas dan pengalaman pengguna.

4. Tidak menyiapkan idempotency

Pada sistem AI, retry sangat umum terjadi: webhook ganda, job diproses ulang, timeout provider, atau worker restart. Tanpa idempotency key atau state transition yang aman, data akan duplikat atau status menjadi tidak konsisten.

5. Observability datang belakangan

Jika Anda baru menambahkan logging dan tracing setelah sistem mulai kompleks, diagnosis biaya token, latensi retrieval, atau job gagal akan sangat lambat. Untuk produk AI, observability bukan fitur tambahan; itu bagian dari core engineering.

6. Mengekstrak service sebelum kontrak domain stabil

Jika API internal berubah tiap minggu, memecah domain menjadi service terpisah hanya memperbanyak migrasi dan incompatibility.

Roadmap 90 hari: dari MVP ke scale-up kecil

Roadmap berikut cocok untuk tim kecil yang ingin cepat masuk ke pasar atau memanfaatkan momentum program AI.

Hari 1-30: MVP yang bisa diuji pengguna

  • Pilih monolit modular dengan satu API utama dan satu worker async.
  • Tetapkan modul inti: auth, documents, retrieval, ai orchestration, observability.
  • Bangun flow minimal: upload dokumen, indexing async, chat dengan retrieval, feedback sederhana.
  • Tambahkan structured logging, request ID, dan metrik dasar: latency, failure rate, job duration.
  • Simpan integrasi provider melalui adapter, jangan hard-code ke banyak tempat.
  • Buat satu pipeline deploy sederhana untuk staging dan production.

Target fase ini: produk bisa didemokan, diuji user, dan tim bisa belajar dari penggunaan nyata.

Hari 31-60: stabilisasi dan kontrol biaya

  • Tambahkan rate limiting, timeout, retry policy, dan dead-letter queue.
  • Ukur biaya per flow: embedding, completion, storage, ingestion.
  • Pisahkan worker berdasarkan jenis beban jika perlu, misalnya ingestion dan evaluation.
  • Perbaiki boundary modul yang mulai bocor.
  • Tambahkan dashboard operasional minimum: antrean job, status dokumen, error provider, latency API.
  • Tulis integration test untuk alur paling penting, bukan mengejar coverage semata.

Target fase ini: sistem tidak hanya bisa demo, tetapi cukup stabil untuk digunakan oleh batch user kecil.

Hari 61-90: scale-up kecil yang terukur

  • Identifikasi modul dengan profil beban paling berbeda.
  • Jika ingestion atau evaluation menjadi bottleneck nyata, pertimbangkan ekstraksi runtime atau service untuk domain itu saja.
  • Perkuat trace propagation dan correlation ID jika ada lebih dari satu runtime utama.
  • Terapkan autoscaling pada worker yang memang terikat antrean.
  • Tinjau security boundary, secret handling, dan akses data per tenant.
  • Dokumentasikan kontrak internal dan ownership domain.

Target fase ini: sistem siap untuk pertumbuhan awal tanpa memecah semua komponen terlalu dini.

Pola keputusan yang paling aman untuk tim kecil

Jika harus diringkas menjadi satu rekomendasi: mulailah dengan monolit modular, tambah queue dan worker untuk beban async, lalu ekstrak service hanya ketika ada alasan operasional yang terukur.

Pendekatan ini cocok untuk tim yang mengejar peluang AI karena menjaga fokus pada hal yang paling penting di awal: menemukan use case, mengirim eksperimen cepat, dan belajar dari data nyata. Anda tetap membangun fondasi yang benar—boundary modul, observability, retry, idempotency, dan deployment discipline—tanpa membayar kompleksitas distributed system sebelum waktunya.

Aturan praktis: bila masalah utama Anda hari ini adalah kualitas produk AI, kecepatan iterasi, dan biaya eksperimen, monolit modular biasanya cukup. Bila masalah utama sudah bergeser ke isolasi beban, batas tim, atau reliabilitas domain tertentu, saat itulah ekstraksi service mulai layak dipertimbangkan.

Pada akhirnya, keputusan arsitektur terbaik bukan yang paling modern, tetapi yang mempercepat pembelajaran dengan risiko operasional yang masih bisa dikendalikan. Untuk sebagian besar tim kecil yang ingin menangkap momentum peluang AI, itu berarti: jangan mulai dari microservices kecuali Anda benar-benar tahu kenapa.