1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02:14 WIB. PagerDuty saya meraung-raung dengan nada paling tinggi, membangunkan saya dari tidur nyenyak. Di layar ponsel, grafik dari Datadog menyala merah terang: latensi endpoint WebSocket melonjak dari rata-rata 45 milidetik menjadi lebih dari 8.500 milidetik, sementara tingkat error HTTP 502 Bad Gateway di balik load balancer Nginx menembus angka 34%. Belum sempat saya membuka laptop, aplikasi Slack kantor sudah dibanjiri pesan dari tim Customer Success bahwa ribuan pengguna di platform e-commerce real-time kami tidak bisa melihat pembaruan status pengiriman maupun perubahan harga kilat secara langsung.

Sebagai Principal Engineer yang bertanggung jawab atas arsitektur infrastruktur skala besar ini, saya tahu persis apa artinya: jantung sistem event-driven kami sedang mengalami serangan jantung massal. Kami mengandalkan kombinasi Apache Kafka sebagai message broker inti, kluster Node.js untuk menangani jutaan koneksi WebSocket, serta jajaran microservices berbasis Go di lapis backend. Ketika salah satu komponen ini mulai tersendat, efek dominonya merambat begitu cepat hingga mengancam seluruh ekosistem web yang kami bangun dengan susah payah.

Tanpa membuang waktu, saya menyeduh secangkir kopi hitam, membuka terminal, dan langsung menerobos masuk ke dalam labirin log produksi untuk mencari tahu siapa pembunuh senyap di balik kekacauan dini hari ini.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Masuk ke dalam server bastion melalui SSH terasa seperti melangkah ke ruang gawat darurat. Langkah pertama saya adalah memeriksa kesehatan reverse proxy di garda terdepan. Melalui terminal, saya memantau akses log Nginx secara real-time untuk melihat pola kegagalan yang terjadi:

sudo tail -f /var/log/nginx/access.log | grep -E "502|504"

Baris demi baris log berkecepatan tinggi memuntahkan pesan upstream timed out dan connection reset by peer. Jelas, para upstream server (dalam hal ini, kluster Node.js yang memegang koneksi WebSocket) tidak mampu merespons dalam batas waktu yang ditentukan (proxy_read_timeout).

[!WARNING] Jangan pernah menaikkan nilai proxy_read_timeout di Nginx sebagai solusi instan untuk masalah latensi backend. Tindakan ini hanya akan menumpuk koneksi ghost di memori dan mempercepat kehabisan deskriptor file (file descriptors) pada sistem operasi.

Saya kemudian beralih memeriksa metrik Kafka menggunakan perangkat CLI bawaan untuk melihat status consumer group pada topik utama pembaruan transaksi:

bin/kafka-consumer-groups.sh --bootstrap-server kafka-cluster:9092 --describe --group websocket-push-service-group

Hasilnya membuat bulu kuduk merinding. Lag pada partisi Kafka membengkak hingga 4.500.000 pesan yang belum terbaca! Layanan pemroses event kami benar-benar lumpuh dan tertinggal jauh di belakang produsen data. Untuk memahami bagaimana situasi runyam ini bisa terjadi, kita harus membongkar akar masalah yang bersembunyi di balik tumpukan kode asinkron kami.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Setelah menggali lebih dalam ke dalam dump memori Node.js dan metrik konsumsi CPU, teka-teki mulai terungkap. Masalah utamanya bukan sekadar lonjakan trafik mendadak, melainkan kegagalan mendasar dalam memahami pola pub/sub versus message streaming, manajemen koneksi WebSocket jutaan klien, serta kegagalan total dalam menangani backpressure pada sistem asinkron.

Secara arsitektural, kami melakukan kesalahan klasik: memperlakukan Kafka (yang merupakan immutable commit log berbasis message streaming) layaknya sistem pub/sub in-memory biasa seperti Redis Pub/Sub. Ketika jutaan klien terhubung melalui WebSocket dan meminta pembaruan data secara masif, layanan gateway WebSocket kami mencoba membaca pesan dari Kafka secepat mungkin tanpa memedulikan kapasitas tampung memori internal (heap Node.js).

// KODE BERMASALAH (ANTIPATTERN)
// Membaca pesan dari Kafka tanpa pembatasan backpressure memicu OOM (Out Of Memory)
consumer.on('data', async (message) => {
    // Mengirim ke jutaan klien WebSocket secara bersamaan tanpa antrean terkontrol
    activeWebSockets.forEach(client => {
        client.send(message.value.toString());
    });
});

Potongan kode di atas adalah bom waktu. Ketika ribuan event masuk per detik dari Kafka, perulangan sinkron ke jutaan objek WebSocket langsung membanjiri antrean pengiriman TCP kernel. Node.js kehabisan ruang heap, memicu Garbage Collector (GC) bekerja secara brutal hingga proses mengalami freeze total (Stop-The-World), yang kemudian membuat Kafka mengira consumer telah mati (heartbeat timeout) dan memicu rebalancing partisi yang tiada akhir. Dari sinilah transisi menuju penanganan darurat harus segera dieksekusi.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit

Situasi sudah kritis dan kita tidak punya waktu untuk melakukan refactoring kode besar-besaran. Yang kita butuhkan adalah stop-gap measure untuk menghentikan pendarahan di infrastruktur. Langkah pertama adalah membatasi tingkat konsumsi pesan dari Kafka menggunakan konfigurasi fetch size yang ketat, serta menerapkan rate limiter berbasis token bucket pada server WebSocket.

Berikut adalah konfigurasi perbaikan cepat pada berkas consumer.properties untuk membatasi beban masuk:

# Batasi ukuran maksimum batch pesan yang ditarik dari Kafka
max.poll.records=500
# Tingkatkan interval timeout untuk mencegah rebalance palsu saat GC
max.poll.interval.ms=300000
session.timeout.ms=45000

Sementara itu, pada sisi aplikasi Node.js, kita menyuntikkan mekanisme backpressure menggunakan pustaka stream bawaan untuk memastikan pengiriman data ke WebSocket tidak melampaui kapasitas buffer TCP soket:

// KODE PERBAIKAN DARURAT
const { Writable } = require('stream');

const backpressureStream = new Writable({
    write(chunk, encoding, callback) {
        // Kirim hanya jika buffer soket masih aman (< 64KB)
        if (client.bufferedAmount < 64 * 1024) {
            client.send(chunk);
            callback();
        } else {
            // Tahan sebentar hingga buffer kosong
            setTimeout(() => callback(), 50);
        }
    }
});

Untuk meredakan beban pada Nginx, kita juga segera menerapkan konfigurasi pembatasan koneksi (limit_conn) dan penyesuaian buffer jaringan:

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;
    
    server {
        location /ws/ {
            limit_conn addr 10;
            proxy_pass http://websocket_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            
            # Optimasi buffer WebSocket
            proxy_buffering off;
            proxy_send_timeout 60s;
            proxy_read_timeout 60s;
        }
    }
}

Dalam waktu kurang dari 15 menit setelah eksekusi skrip darurat ini, grafik latensi mulai turun drastis, dan antrean lag Kafka perlahan-lahan menyusut ke angka nol. Layanan kembali bernapas. Namun, kisah ini belum selesai sampai kita memastikan insiden serupa tidak terulang kembali di masa depan.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Pelajaran pahit malam ini mengajarkan kita bahwa arsitektur event-driven skala besar tidak boleh dibangun di atas asumsi bahwa konsumsi data akan selalu berjalan mulus. Kita harus mengubah paradigma dari sekadar memindahkan data secepat mungkin menjadi mengalirkan data sekokoh mungkin.

Berikut adalah tiga pilar arsitektur defensif baru yang wajib kita terapkan mulai pekan depan:

1. Pemisahan Jalur Berdasarkan Prioritas (Priority Queuing): Jangan pernah mencampuradukkan pesan kritikal (seperti status pembayaran) dengan pesan trivial (seperti indikator 'sedang mengetik') dalam satu saluran konsumsi Kafka yang sama. Kita akan memecah topik Kafka menjadi beberapa lapis prioritas dengan consumer group terisolasi.

2. Implementasi Backpressure End-to-End yang Ketat: Mengadopsi pola reactive streams di seluruh rantai layanan mikro berbasis Go dan Node.js. Jika klien WebSocket lambat membaca data, sistem harus secara elegan memutus koneksi atau melakukan drop pada pesan non-esensial daripada menumpuknya di memori peladen.

3. Penyempurnaan Skala Horizontal (Horizontal Auto-Scaling): Menghubungkan HPA (Horizontal Pod Autoscaler) di Kubernetes tidak hanya berdasarkan penggunaan CPU, melainkan langsung mengacu pada metrik Consumer Lag dari Kafka menggunakan Prometheus Adapter.

6. Pasang Alarm: Otomasi Deteksi Dini untuk Tim On-Call

Agar kita tidak lagi bergantung pada kepanikan tengah malam atau laporan pengguna yang marah, sistem pemantauan harus dibuat seproaktif mungkin. Kita memasang aturan alerting baru di Prometheus dan Alertmanager yang akan mendeteksi gejala awal sebelum bencana benar-benar terjadi.

Berikut adalah aturan alert Prometheus yang wajib aktif di lingkungan produksi:

groups:
  - name: kafka-websocket-alerts
    rules:
      - alert: KafkaConsumerLagHigh
        expr: sum(kafka_consumergroup_lag{topic="transactions-stream"}) by (consumergroup) > 50000
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Consumer lag sangat tinggi pada layanan WebSocket!"
          description: "Lag Kafka telah melampaui 50.000 pesan selama lebih dari 2 menit. Segera periksa kapasitas consumer."

      - alert: WebSocketMemoryLeakWarning
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 15
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Memori peladen menipis drastis!"
          description: "Sisa memori kurang dari 15%, potensi OOM pada kluster Node.js."

      - alert: NginxHigh502ErrorRate
        expr: sum(rate(nginx_http_requests_total{status=~"502"}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100 > 5
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: "Lonjakan error 502 Bad Gateway di Nginx!"
          description: "Tingkat error 502 melampaui 5% dari total trafik web."

Dengan aturan alarm yang presisi ini, tim on-call kini memiliki waktu tanggap yang cukup sebelum sistem mengalami kelumpuhan total. Arsitektur event-driven kita kini jauh lebih tangguh, siap menghadapi badai trafik apa pun di masa depan.