Rate Limit dan Retry Policy: Optimasi Infrastruktur Bot Trading

Masalah: Bottleneck pada REST API

Dalam pengembangan infrastruktur bot, interaksi dengan REST API exchange adalah titik krusial. Setiap exchange menerapkan batasan jumlah permintaan dalam periode waktu tertentu untuk mencegah penyalahgunaan sumber daya. Ketika bot Anda melampaui ambang batas ini, server akan merespons dengan HTTP 429 Too Many Requests. Jika tidak ditangani secara sistematis, bot akan mengalami kegagalan eksekusi, kehilangan sinkronisasi data pasar, atau bahkan terkena blokir IP sementara oleh penyedia layanan.

Desain: Strategi Komunikasi yang Resilien

Infrastruktur yang baik tidak hanya mengirim permintaan, tetapi juga memantau kesehatan koneksi. Desain yang disarankan melibatkan tiga lapisan:

1. Rate Limiter Lokal: Menahan laju permintaan di sisi client sebelum mencapai batas exchange.
2. Error Handling: Menangkap status code 429 dan mengevaluasi header Retry-After.
3. Backoff Strategy: Mengatur jeda waktu pengiriman ulang agar tidak membebani server saat sedang sibuk.

Langkah Implementasi

1. Implementasi Rate Limiter Sisi Client

Sebelum mengirim request, pastikan bot memiliki mekanisme antrean atau token bucket untuk mengontrol laju permintaan agar tetap di bawah limit yang ditentukan oleh dokumentasi exchange.

2. Menangkap HTTP 429 dan Membaca Retry-After

Saat menerima respon 429, jangan langsung mencoba kembali secara instan. Periksa header Retry-After yang dikirimkan oleh server.

import time
import requests

def execute_request(url, headers):
    response = requests.get(url, headers=headers)
    if response.status_code == 429:
        wait_time = int(response.headers.get("Retry-After", 1))
        time.sleep(wait_time)
        return execute_request(url, headers) # Rekursi sederhana
    return response

3. Backoff Eksponensial

Jika server tidak memberikan header Retry-After, gunakan algoritma backoff eksponensial. Ini mencegah "thundering herd problem" di mana banyak instance bot mencoba terhubung kembali di saat yang bersamaan.

Pitfall Produksi

• Mengabaikan Header: Tidak membaca Retry-After memaksa bot melakukan banyak request sia-sia yang justru memperpanjang masa hukuman dari sisi server.
• Sinkronisasi Waktu: Ketidakcocokan waktu antara lokal server dan server exchange dapat menyebabkan masalah otentikasi saat mencoba melakukan retry.
• Logging Berlebihan: Terlalu banyak mencatat kegagalan di level log produksi dapat memenuhi disk dan mengaburkan metrik performa utama.

Checklist Operasional

• [ ] Pastikan semua credential disimpan dalam environment variables, bukan hardcoded.
• [ ] Terapkan mekanisme idempotency pada setiap request order agar retry tidak menyebabkan double execution.
• [ ] Pantau metrik jumlah status 429 di dashboard monitoring infrastruktur Anda.
• [ ] Gunakan circuit breaker pattern jika tingkat kegagalan (error rate) melampaui ambang batas tertentu.

FAQ

Apakah aman melakukan retry tanpa batas waktu?

Tidak disarankan. Anda harus menetapkan batas maksimal percobaan (max retries) untuk menghindari infinite loop yang menghabiskan memori dan sumber daya infrastruktur.

Bagaimana cara membedakan rate limit dengan masalah koneksi jaringan?

Rate limit selalu memberikan kode respons HTTP 429. Jika masalahnya adalah koneksi, Anda biasanya akan menemui timeout atau koneksi ditolak (refused) yang memerlukan strategi penanganan berbeda, seperti retry dengan interval tetap atau pengecekan status API secara berkala.