Pembukaan dan Diagnosa Awal

Ketika traffic naik, microservice Go kami mulai memicu timeout serentak sehingga request menumpuk, latency rata-rata meningkat drastis, dan log menampilkan error timeout yang seragam. Masalah utama bukan hanya satu panggilan gagal, tetapi semua instance mengalami timeout pada layer bisnis yang berbeda, yang mengindikasikan bottleneck shared seperti koneksi database atau batas context timeout upstream.

Dalam 1-2 paragraf ini, perspektif utama telah dijelaskan: gejala timeout massif di microservice Go ketika trafik tinggi, dengan fokus pada troubleshooting yang memetakan root cause sebelum menerapkan perbaikan.

1. Gejala Timeout Serentak

Gejala yang mencolok terlihat dari observabilitas awal:

  • Antrean request menumpuk di reverse proxy dan sidecar, terlihat dari meningkatnya queue_time di tracing.
  • Latency meningkat di histogram HTTP, tetapi tail latency (p99-p999) sangat tinggi dibandingkan p50.
  • Log timeout berulang di semua endpoint yang memanggil service downstream atau database: context deadline exceeded atau sql: database is closed.

Jika microservice menggunakan circuit breaker atau rate limiter, kemacetan bisa dipicu saat semua request menunggu sumber daya terbatas. Identifikasi awal harus fokus pada stack trace, go env, dan tracing distribusi untuk melihat pada layer mana timeout terjadi.

2. Penelusuran Root Cause

2.1 Pool Koneksi Database Habis karena Retry Agresif

Retry otomatis yang terlalu agresif (terutama dengan exponential backoff yang pendek) dapat menguras pool database. Jika setiap permintaan yang gagal melakukan 3 retry cepat, jumlah koneksi simultan bisa melebihi MaxOpenConns dan menyebabkan semua goroutine menunggu.

Contoh konfigurasi DB yang terlalu dekat:

db.SetMaxOpenConns(50)
db.SetConnMaxIdleTime(5 * time.Second)

Ketika tier API menerima 1.000 rps, konfigurasi ini tidak bisa skala karena setiap retry menambah hold waktu koneksi.

2.2 Context Timeout Terlalu Pendek untuk Downstream

Timeout context yang pendek mengakibatkan permintaan dibatalkan sebelum downstream selesai. Ini memicu retry dari client, yang justru memperburuk beban downstream.

Contoh pattern problematik:

ctx, cancel := context.WithTimeout(r.Context(), 200*time.Millisecond)
defer cancel()
resp, err := downstreamClient.Do(req.WithContext(ctx))

Jika downstream memerlukan 350 ms saat trafik tinggi (penjadwalan GC, locking), timeout 200 ms berarti semua permintaan berakhir dengan timeout.

3. Langkah Perbaikan Konkret

3.1 Adjust Timeout dan Batasan Retry

Tingkatkan timeout context dengan mengukur latency tail yang realistis, misalnya 500 ms. Jangan memaksakan timeouts terlalu agresif; gunakan context.WithTimeout yang sesuai.

ctx, cancel := context.WithTimeout(r.Context(), 750*time.Millisecond)
defer cancel()
resp, err := downstreamClient.Do(req.WithContext(ctx))

Batas waktu ini memberi ruang untuk beban puncak dan mengurangi abort paksa.

Untuk retry, gunakan circuit breaker/limit untuk mengontrol beban:

for i := 0; i < maxRetries; i++ {
    if err := callDownstream(ctx); err == nil {
        return nil
    }
    time.Sleep(backoff(i))
}

Konfigurasi backoff harus menambah durasi secara eksponensial dan berhenti setelah beberapa kali agar tidak menumpuk request.

3.2 Observabilitas Tambahan

Pasang metrik berikut di service:

  • Jumlah goroutine aktif untuk melihat penumpukan.
  • Latency histogram per endpoint, per panggilan database, dan per downstream.
  • Hitungan retry dan waktu tunggu pool koneksi.

Dengan tracing distribusi, lihat apakah timeout berasal dari client atau downstream; jika client, optimalkan request clientnya. Jika downstream tidak responsif, pertimbangkan caching hasil atau fallback sederhana.

3.3 Mitigasi dan Fallback

Tambahkan fallback ketika dependency kritis lambat:

  • Gunakan cache lokal (misal groupcache) untuk data yang jarang berubah.
  • Terapkan response fallback sederhana (konten default) agar client tidak menunggu terlalu lama.

Fallback mengurangi tekanan pada downstream saat terjadi beban ekstrem.

4. Tips Debug dan Praktik Pencegahan

  • Baca log latency saat load testing: timbang tail latency, bukan hanya mean.
  • Gunakan pprof dan heap dump: untuk melihat apakah goroutine menunggu resource.
  • Set timeout dan retry di level client dan server: Konsistensi ini menolong readability dan koordinasi antar tim.
  • Monitor pool koneksi: Tools seperti pg_stat_activity atau metrics internal membantu mengetahui apakah semua koneksi terpakai.

Kesalahan umum: menurunkan timeout tanpa meningkatkan kapasitas pool; ini memperpendek siklus timeout tanpa menyelesaikan bottleneck.

Kesimpulan

Debugging timeout serentak pada microservice Go melibatkan pengamatan gejala antrean dan log timeout, diagnosis root cause pada pool koneksi atau timeout context, serta perbaikan konkret berupa penyesuaian timeout, pembatasan retry, observabilitas lebih, dan fallback. Pendekatan pragmatis seperti ini membantu mengembalikan kestabilan sistem saat trafik naik drastis.