Retry Strategy #

Dalam sistem software modern—terutama yang berbasis distributed system, microservices, dan cloud-native architecture—kegagalan bukanlah sesuatu yang jika terjadi, melainkan kapan terjadi. Network glitch, timeout, throttling, race condition, hingga temporary outage adalah bagian dari realita sehari-hari.

Di sinilah Retry Strategy berperan penting. Retry yang dirancang dengan baik dapat meningkatkan reliability dan resilience sistem secara signifikan. Namun retry yang salah justru bisa memperparah masalah, menyebabkan cascading failure, traffic storm, bahkan system meltdown.

Artikel ini membahas retry strategy secara mendalam: mulai dari konsep dasar, jenis-jenis retry, kapan boleh dan tidak boleh retry, hingga best practice implementasinya.

Apa Itu Retry Strategy? #

Retry Strategy adalah pendekatan sistematis untuk mencoba kembali (retry) sebuah operasi yang gagal, dengan aturan dan batasan tertentu.

Retry bukan sekadar loop ulang. Retry strategy mencakup:

• Kapan retry dilakukan
• Berapa kali retry
• Jarak antar retry
• Kondisi kegagalan apa yang boleh di-retry
• Kapan harus berhenti dan fail fast

Retry strategy umumnya diterapkan pada:

• HTTP request antar service
• Database operation
• Message processing (Kafka, SQS, Pub/Sub)
• External API call
• Background job / worker

Mengapa Retry Strategy Penting? #

Kegagalan Bersifat Sementara (Transient Failure) #

Banyak error bersifat sementara:

• Network timeout
• DNS hiccup
• Service overload sementara
• Cold start pada serverless

Retry dengan delay kecil sering kali cukup untuk membuat operasi berhasil.

Meningkatkan Reliability Tanpa Intervensi Manual #

Tanpa retry:

• Error kecil langsung menjadi incident
• Banyak false alarm

Dengan retry:

• Sistem lebih self-healing
• Incident rate menurun

Retry Adalah Fondasi Resilience Pattern #

Retry strategy sering dikombinasikan dengan:

• Circuit Breaker
• Bulkhead
• Timeout
• Rate Limiting

Tanpa retry yang benar, pola-pola ini menjadi kurang efektif.

Retry vs Retry Strategy #

Jenis-Jenis Retry Strategy #

Immediate Retry #

Retry langsung tanpa jeda.

Kelebihan:

• Cepat
• Sederhana

Kekurangan:

• Membebani sistem
• Hampir selalu buruk di production

Gunakan hanya untuk:

• In-memory operation
• Operasi lokal yang sangat murah

Fixed Delay Retry #

Retry dengan jeda waktu tetap.

Contoh:

• Retry setiap 1 detik, maksimal 3 kali

Masalah utama:

• Thundering herd problem jika banyak request retry bersamaan

Exponential Backoff (Paling Umum) #

Delay bertambah secara eksponensial.

Contoh:

• 100ms → 200ms → 400ms → 800ms

Kelebihan:

• Memberi waktu sistem pulih
• Mengurangi pressure

Kekurangan:

• Tanpa batas maksimum bisa terlalu lama

Exponential Backoff + Jitter (Best Practice) #

Menambahkan randomisasi pada delay.

Contoh:

• 400ms ± random(0–100ms)

Manfaat utama:

• Menghindari retry serentak
• Sangat penting di distributed system

Ini adalah retry strategy yang paling direkomendasikan.

Limited Retry (Max Attempt) #

Retry selalu memiliki batas.

Contoh:

• Max 3 atau 5 attempt

Tanpa batas:

• Infinite loop
• Resource leak

Retry dengan Deadline / Timeout Budget #

Retry dilakukan selama masih dalam time budget.

Contoh:

• Total waktu retry tidak boleh lebih dari 2 detik

Pendekatan ini sering digunakan di sistem latency-sensitive.

Retry Berdasarkan Jenis Error #

Error yang BOLEH di-Retry #

• Timeout
• Connection reset
• HTTP 429 (Too Many Requests)
• HTTP 5xx (tertentu)
• Temporary unavailable

Error yang TIDAK BOLEH di-Retry #

• Validation error (400)
• Authentication / authorization error (401, 403)
• Business logic error
• Data tidak valid

Rule of thumb:

Jika retry tidak akan mengubah hasil, jangan retry.

Retry dan Idempotency #

Retry harus mempertimbangkan idempotency.

Masalah Umum #

Jika operasi tidak idempotent, retry bisa menyebabkan:

• Double charge
• Duplicate order
• Data corruption

Solusi #

• Gunakan idempotency key
• Pastikan operasi bisa dijalankan ulang dengan hasil yang sama

Retry tanpa idempotency adalah bug laten.

Retry di Berbagai Layer Sistem #

Retry di Client Side #

• HTTP client
• SDK
• Frontend → Backend

Kelebihan:

• Dekat dengan source error

Risiko:

• Duplicate retry jika server juga retry

Retry di Server Side #

• Service-to-service call
• Internal processing

Best practice:

• Retry hanya di satu layer
• Hindari retry berlapis

Retry di Message Consumer #

Retry sangat umum pada:

• Kafka consumer
• SQS / PubSub subscriber

Biasanya dikombinasikan dengan:

• Dead Letter Queue (DLQ)
• Retry topic / retry queue

Retry vs Replay Strategy #

Retry menangani failure sementara, replay menangani failure struktural.

Anti-Pattern Retry yang Harus Dihindari #

Infinite Retry #

• Membuat sistem stuck
• Menghabiskan resource

Retry Tanpa Delay #

• DDoS ke service sendiri

Retry Semua Error #

• Menyembunyikan bug logic

Retry Tanpa Observability #

Tanpa log dan metric:

• Sulit debug
• Sulit tuning

Best Practice Retry Strategy #

1. Gunakan exponential backoff + jitter
2. Batasi jumlah retry
3. Retry hanya untuk error yang transient
4. Pastikan operasi idempotent
5. Gunakan timeout dan deadline
6. Kombinasikan dengan circuit breaker
7. Tambahkan metric: retry count, retry success rate
8. Dokumentasikan retry behavior

Contoh Konsep Retry Ideal (Pseudo Flow) #

1. Request gagal
2. Cek apakah error retryable
3. Cek apakah retry count < max
4. Hitung delay (backoff + jitter)
5. Tunggu
6. Retry
7. Jika gagal terus → fail fast atau DLQ

Penutup #

Retry strategy adalah salah satu low-level decision yang dampaknya sangat besar pada stabilitas sistem. Implementasi retry yang benar dapat membuat sistem tahan banting, sementara retry yang salah bisa menjadi sumber outage.

Jika ada satu kalimat untuk dirangkum:

Retry bukan tentang mencoba lagi, tapi tentang mencoba lagi dengan cara yang benar.

Di sistem berskala besar, retry strategy bukan opsional—ia adalah engineering discipline.