Ketika Zuckerberg menyebut pengembangan AI agent berjalan lebih lambat dari yang diharapkan, pilihan arsitektur menjadi penentu utama agar tim bisa menjaga kualitas tanpa mengorbankan iterasi. Pendekatan microservices dan modular monolith perlu ditimbang berdasarkan latency, biaya operasional, serta maintainability, terutama saat tim kecil menyiapkan peluncuran bertahap.

Pembukaan seperti ini menjawab langsung kebutuhan menilai apakah arsitektur yang dipilih bisa menghadapi ekspektasi performa yang belum tercapai dan menampung pertumbuhan aktivitas agent yang mengalami throttling.

Perbandingan arsitektur: microservices vs modular monolith

Arsitektur yang dipilih memengaruhi pengukuran performa, respons terhadap throttling, dan kecepatan iterasi. Di bawah ini kita bedakan aspek-aspek kunci.

Latency dan konsistensi respons

Microservices mengisolasi kemampuan (misalnya intent classification, dialog manager, eksekusi tindakan) dalam layanan terpisah. Keuntungan utamanya ialah skala horizontal untuk bagian yang paling banyak dipanggil. Namun komunikasi antar layanan meningkatkan latency puncak ketika terjadi throttling pada salah satu layanan. Latency 95th percentile dapat melesat jika tidak ada circuit breaker atau bulkhead. Untuk tim kecil, perawatan dependencies ini bisa memperlambat debugging.

Modular monolith mengemas komponen-komponen tersebut dalam satu proses dengan boundary modul yang jelas. Latency intra-proses lebih rendah karena tidak ada RPC, dan topologi pengujian lebih sederhana. Dengan kontrol thread dan resource yang tepat (misalnya bounded worker pool), tim kecil bisa mempertahankan throughput sambil memantau latensi. Namun, peningkatan beban pada satu modul bisa menular ke seluruh aplikasi jika tidak ada throttling internal.

Biaya operasional dan skala

Microservices memungkinkan menyalakan instance hanya untuk modul yang mengalami beban tinggi, yang membantu menekan biaya saat agen belum memasuki tahap pertumbuhan. Di sisi lain, arsitektur ini butuh observability (tracing, distributed logs) yang kompleks dan menambah biaya licence/ops untuk tim kecil. Modular monolith memerlukan lebih sedikit servis infrastruktur—karena hanya satu deployment unit—dan bisa berjalan di satu cluster yang sama, sehingga biaya menghadapi increment beban terkendali.

Maintainability dan tim terbatas

Dalam microservices, tim harus menguasai deployment pipeline, orchestrator (misal Kubernetes), dan versioning API antar layanan. Ini menantang bagi tim kecil yang partisipasinya multirole. Kelebihan modular monolith adalah mudahnya refactor antar modul tanpa memperbaharui kontrak antar servis, sehingga tim kecil bisa lebih cepat mengadaptasi perubahan pada AI agent.

Pilih microservices jika: (1) beban sangat tidak merata dan memerlukan scaling terpisah, (2) ada tim DevOps khusus, dan (3) Anda mampu menyeimbangkan latency tambahan dengan caching/prefetching. Pilih modular monolith jika: (1) fokus pada pengembangan cepat dan debugging lokal, (2) tim terbatas, (3) Anda membutuhkan kontrol penuh terhadap integrasi internal.

Metrik kematangan dan throttling dalam konteks peluncuran bertahap

Untuk memutuskan kapan menambah kapasitas, gunakan metrik yang mencerminkan latency, biaya, dan maintainability. Beberapa metrik utama:

  • Latency P95/P99 per modul (atau endpoint) untuk mencerminkan dampak throttling. Gunakan aggregator seperti Prometheus + Grafana untuk memonitor distribusi respons.
  • Drop rate atau rate limit rejection pada integrasi ke eksternal. Ini menandakan bahwa throttling sudah terjadi dan perlu pacing backlog.
  • Time-to-deploy dan Mean Time To Recovery (MTTR) untuk menilai maintainability; perhatikan apakah pipeline memperlambat perbaikan ketika agent menerima feedback pengguna.
  • Biaya operasi per throughput (misalnya dasar dollar per 1.000 request/second) untuk melihat apakah arsitektur mengurangi efisiensi saat skala kecil.

Contoh aturan alert Prometheus untuk memantau throttling:

ALERT AgentThrottled
  IF rate(agent_requests_denied_total[1m]) > 5
  FOR 5m
  LABELS { severity="warning" }
  ANNOTATIONS {
    summary="Throttling tinggi pada AI agent",
    description="Lebih dari 5 permintaan per menit ditolak karena throttling. Tinjau worker pool atau tambahkan buffering."
  }

Aturan semacam ini membantu menunjuk area arsitektur yang perlu scaling saat peluncuran bertahap.

Langkah memilih dan memantau arsitektur untuk peluncuran bertahap

Untuk agent yang diluncurkan secara bertahap, arsitektur harus adaptif. Berikut panduan langkah demi langkah.

  1. Tentukan fase peluncuran: identifikasi jumlah pengguna awal, diversitas input, dan KPI latency biaya. Saat fase awal, modular monolith bisa lebih efisien; evaluasi kebutuhan scale-out setelah fase integrasi.
  2. Identifikasi batas domain: pisahkan kemampuan yang mungkin perlu skala mandiri (seperti inference heavy) dalam servis modular. Gunakan bounded context atau plugin module agar tetap bisa di-skala secara terpisah di masa depan.
  3. Bangun observability sejak awal: terapkan tracing, metrics, logging yang konsisten. Catat per modul (atau per endpoint) agar throttling mudah dipantau. Ini akan berguna jika nanti perlu memisahkan modul menjadi microservices.
  4. Rencanakan eksperimen arsitektur: gunakan feature toggles atau side-by-side deployment agar Anda bisa memindahkan modul dari monolith ke microservices tanpa gangguan layanan utama.
  5. Kaji biaya dan maintainability secara periodik: gunakan data biaya cloud/per hit untuk melihat apakah microservices memang menghemat biaya atau hanya menambah kompleksitas.
  6. Gunakan alarm dan runbook: susun runbook yang merekam langkah recovery, terutama saat throttling meningkatkan latency. Runbook harus menyebutkan prioritas penanganan modul tersebut.

Dengan pendekatan ini, tim kecil bisa memulai dengan arsitektur modular yang mudah dikontrol, kemudian secara bertahap mengadopsi microservices untuk bagian yang memerlukan skala lebih besar.

Penyesuaian terus-menerus berdasarkan metrik nyata dan praktik perbaikan berkelanjutan membuat ekspektasi performa yang tertunda bisa dikelola tanpa mengambil risiko arsitektur yang berlebihan.