DIPERBARUI: 2026-11-06
[A3-M4]Mahirā± 45 Mnt Baca + 70 Mnt Praktik

Deployment Agen Produksi: Antrean Tugas, Retry & Idempotensi

Menjaga Agen Tetap Tangguh di Lingkungan Produksi Tanpa Duplikasi Transaksi

BAGIKAN MODUL:
[KONTRAK HASIL BELAJAR // A3-M4]Standar Kompetensi Industri
ā± 45 Mnt Bacaā€¢āš” 70 Mnt Praktik•Lulus: ≄ 80/100 Poin

01. Target Pembelajar & Prasyarat

DevOps, SRE, dan production backend engineer.

02. Kompetensi Konseptual (Level 1–2)

  • āœ“Menjelaskan konsep idempotency key pada pemanggilan alat API.

03. Kompetensi Praktis & Artefak Nyata (Level 3–4)

  • āœ“Membangun mekanisme exponential backoff retry pada loop agen.
Artefak yang Dibangun: Handler agen produksi `resilient-agent-runner.mjs`.

04. Aplikasi Nyata & Verifikasi

Penerapan Industri: Infrastruktur endpoint pesanan Z-Automation (/api/orders).

Metode Verifikasi: Memverifikasi bahwa kegagalan API acak dapat dipulihkan secara otomatis tanpa mengirim pesanan ganda.

[BAGIAN 01 // MASALAH & URGENSI ARSITEKTURAL]

Mengapa Subjek Ini Krusial dalam Rekayasa Nyata?

Pelajari arsitektur antrean tugas (Message Queue), penerapan exponential backoff untuk rate limit, dan kunci idempotensi untuk mencegah transaksi ganda.

Dalam lingkungan produksi, kegagalan memahami batas-batas arsitektur sistem sering kali menyebabkan bug yang sulit dilacak, pemborosan biaya komputasi, atau antarmuka yang lambat bagi pengguna.

[BAGIAN 02 // MEKANISME DI BALIK LAYAR]

Bagaimana Sistem Sebenarnya Bekerja di Tingkat Protokol

Pilar Ketangguhan Sistem di Produksi

Di lingkungan produksi, kegagalan bukan kemungkinan; kegagalan adalah kepastian. Penyedia API model bisa mengalami downtime singkat, koneksi jaringan bisa putus di tengah jalan, atau kuota laju permintaan (rate limit) tercapai.

Kita menerapkan tiga pertahanan utama: 1) Kunci Idempotensi (Idempotency Key) agar request berulang tidak membuat transaksi ganda, 2) Exponential Backoff Retry agar tidak membanjiri server yang sedang sakit, dan 3) Circuit Breaker.

[DIAGRAM TEKNIS SVG INTERAKTIF // DIAG-01]

Alur Arsitektur Sistem Otonom & Runtime

LANGKAH 1 DARI 4
ENTITAS AKTIF:User -> Sistem
01
02
03
04

Pesan bahasa alami diterima melalui antarmuka web atau webhook chat.

[LIVE PAYLOAD INSPECTOR]JSON 2026
{
  "input": "Berapa estimasi biaya pembuatan landing page bisnis?"
}
[BAGIAN 03 // MATRIKS KESALAHPAHAMAN]

Koreksi Asumsi Umum vs Realitas Rekayasa

ƗASUMSI KELIRU

ā€œCukup menambahkan try/catch sederhana agar agen tahan banting di produksi.ā€

āœ“REALITAS SISTEM

Tanpa mekanisme retry bertahap (exponential backoff) dan kunci idempotensi, sistem akan gagal saat terkena rate limit atau menagih pelanggan dua kali.

[BAGIAN 04 // LABORATORIUM PRAKTIS & KODE]

Implementasi Langkah-demi-Langkah

Hasil akhir yang diharapkan: Runner dengan retry exponential backoff yang berhasil setelah percobaan kedua.

STRUKTUR PROYEK DIREKOMENDASIKAN:
lab-a3-m4/
└── retry-runner.mjs

1Implementasi Retry dengan Exponential Backoff

Mencoba ulang dengan jeda waktu yang meningkat secara eksponensial.

retry-runner.mjs•javascript
āœ“Tested Successfully
LINGKUNGAN TERUJI: Node.js v20.10.024 BARIS KODE
1// retry-runner.mjs
2async function panggilDenganRetry(operasiFn, maxRetry = 3, delayAwalMs = 100) {
3 let attempt = 0;
4 while (attempt < maxRetry) {
5 try {
6 attempt++;
7 return await operasiFn(attempt);
8 } catch (err) {
9 if (attempt >= maxRetry) throw err;
10 const delay = delayAwalMs * Math.pow(2, attempt - 1);
11 console.log(`[RETRY #${attempt}] Gagal (${err.message}). Menunggu ${delay}ms sebelum mencoba lagi...`);
12 await new Promise(r => setTimeout(r, delay));
13 }
14 }
15}
16
17// Simulasi operasi yang gagal sekali sebelum sukses
18const operasiFlaky = async (attempt) => {
19 if (attempt === 1) throw new Error('429 Rate Limit Exceeded');
20 return 'Sukses pada percobaan ke-' + attempt;
21};
22
23const hasil = await panggilDenganRetry(operasiFlaky);
24console.log('Hasil Akhir:', hasil);
KEPUTUSAN ARSITEKTURAL UTAMA:
• Exponential delay with jitter: Mencegah fenomena thundering herd saat banyak worker mencoba ulang bersamaan.
PERINTAH EKSEKUSI TERMINAL:
$ node retry-runner.mjs
OUTPUT YANG DIHARAPKAN:
[RETRY #1] Gagal (429 Rate Limit Exceeded)...
Hasil Akhir: Sukses pada percobaan ke-2
[BAGIAN 05 // PANDUAN TROUBLESHOOTING & TANTANGAN]

Mengantisipasi Masalah Umum & Tantangan Ekstensi

Pesan Error: Retry tidak pernah berhenti
Penyebab: Kondisi loop salah
Solusi Eksak: Pastikan attempt bertambah di setiap iterasi.
⚔ TANTANGAN EKSTENSI MANDIRI:

Tambahkan idempotency key acak (UUID) pada setiap request.

[RUBRIK EVALUASI KOMPETENSI 100 POIN // A3-M4]

Uji Kompetensi Mandiri & Verifikasi Hasil

Standar kelulusan Z-Automation mewajibkan skor minimum 80 / 100 Poin dengan komponen Implementasi Praktis minimal 21 / 35 Poin (60%). Jawab soal diagnostik dan centang hasil pengujian praktis Anda.

BAGIAN A // PERTANYAAN DIAGNOSTIK KONSEPTUAL & TEKNIS (40 POIN)

01.Mengapa exponential backoff lebih baik daripada fixed delay retry (misal menunggu 1 detik terus-menerus)?

BAGIAN B // DAFTAR PERIKSA HASIL IMPLEMENTASI PRAKTIS (35 POIN — MIN. 21 POIN)

Centang item di bawah ini hanya jika Anda telah menjalankan kode di komputer Anda dan mengamati output yang benar:

Lanjutkan Menggulir
untuk Eksplorasi
Edukasi & Lab
Halaman Selanjutnya