Automatic Retry Policy adalah sebuah pola desain perangkat lunak (software design pattern) di mana aplikasi secara otomatis mencoba mengulangi operasi yang gagal—biasanya permintaan jaringan atau kueri basis data—dengan harapan bahwa kegagalan tersebut bersifat sementara (transient) dan percobaan berikutnya akan berhasil. Pola ini sangat vital dalam arsitektur terdistribusi dan layanan berbasis mikroservis untuk memastikan ketahanan sistem (resilience) terhadap gangguan koneksi atau beban puncak.
Tanpa mekanisme penundaan yang cerdas, pengulangan yang dilakukan secara membabi buta justru dapat memperparah kondisi server tujuan melalui fenomena yang disebut thundering herd atau lonjakan trafik buatan. Oleh karena itu, penerapan standar industri selalu menggabungkan aturan coba ulang dengan strategi penundaan waktu tertentu.
Komponen Utama dalam Kebijakan Coba Ulang
Sebuah konfigurasi kebijakan pengulangan yang aman dan efisien terdiri dari beberapa parameter pengendali utama:
| Parameter | Fungsi Utama | Contoh Nilai Umum |
|---|---|---|
| Max Retries | Batasan maksimal jumlah percobaan ulang sebelum menyerah. | 3 - 5 kali |
| Initial Interval | Waktu tunggu awal sebelum percobaan ulang pertama dilakukan. | 1 detik |
| Backoff Multiplier | Faktor pengali untuk melipatgandakan waktu tunggu pada setiap percobaan berikutnya. | 2 (Eksponensial) |
| Max Interval | Batas atas waktu tunggu maksimal agar tidak terjadi penundaan yang terlalu lama. | 30 - 60 detik |
| Jitter | Variasi acak yang ditambahkan ke waktu tunggu untuk menghindari bentrokan trafik (collision). | Full Jitter / Equal Jitter |
Strategi Waktu Tunggu (Backoff Strategies)
Pemilihan algoritma penundaan menentukan seberapa ramah aplikasi Anda terhadap infrastruktur backend:
1. Fixed Interval (Jeda Tetap)
Aplikasi menunggu dalam durasi yang sama pada setiap percobaan ulang (misalnya selalu 2 detik). Strategi ini sederhana namun berisiko tinggi membebani server jika banyak klien mengalami kegagalan secara bersamaan.
2. Exponential Backoff (Jeda Eksponensial)
Waktu tunggu dilipatgandakan secara eksponensial pada setiap kegagalan berikutnya (contoh: 1s, 2s, 4s, 8s, 16s). Ini memberikan waktu bagi server yang kelebihan beban untuk memulihkan diri.
3. Exponential Backoff with Jitter
Penambahan elemen acak (jitter) pada perhitungan eksponensial membuat klien-klien tidak melakukan permintaan ulang pada detik yang persis sama, sehingga meratakan distribusi beban (load distribution).
Contoh Implementasi Kode (Python)
Berikut adalah contoh implementasi fungsi pengulangan otomatis menggunakan skema Exponential Backoff dengan Jitter dalam bahasa pemrograman Python:
import time
import random
def call_external_service():
# Mensimulasikan panggilan API yang gagal 70% dari waktu
if random.random() < 0.7:
raise ConnectionError("Koneksi jaringan gagal sementara")
return "Sukses"
def retry_with_exponential_backoff(max_retries=4, base_delay=1, max_delay=30):
retries = 0
while retries < max_retries:
try:
return call_external_service()
except ConnectionError as e:
retries += 1
if retries >= max_retries:
raise e
# Hitung waktu tunggu eksponensial dengan batas maksimum
exponential_delay = min(max_delay, base_delay * (2 ** (retries - 1)))
# Tambahkan jitter acak (0 hingga 1 detik)
jitter = random.uniform(0, 1)
sleep_time = exponential_delay + jitter
print(f"Percobaan {retries} gagal. Mencoba lagi dalam {sleep_time:.2f} detik...")
time.sleep(sleep_time)
# Menjalankan fungsi
try:
result = retry_with_exponential_backoff()
print(f"Hasil akhir: {result}")
except Exception as e:
print(f"Operasi gagal total setelah batas maksimal tercapai: {e}")
Praktik Terbaik dan Jebakan Umum
Penerapan kebijakan coba ulang harus dilakukan secara hati-hati agar tidak menimbulkan efek samping yang merusak:
- Idempotensi API: Pastikan operasi yang diulang bersifat idempoten (aman jika dieksekusi berkali-kali tanpa mengubah hasil akhir). Operasi seperti pembayaran atau transfer uang memerlukan token unik (idempotency key) sebelum menerapkan retry otomatis.
- Hindari Retry pada Kesalahan Klien (4xx): Jangan pernah mengulang permintaan yang menghasilkan kode status HTTP 400 (Bad Request), 401 (Unauthorized), atau 404 (Not Found), karena kesalahan tersebut bersumber dari logika atau data pengirim yang tidak akan berubah meski dicoba ribuan kali. Fokuskan retry hanya pada galat jaringan atau kode server (5xx dan timeout).
- Tentukan Batas Waktu Keseluruhan (Timeout): Kombinasikan retry dengan batas waktu total (deadline) agar aplikasi tidak terjebak dalam proses pengulangan tanpa akhir ketika layanan benar-benar down.