Optimistic UI memberikan respons visual instan pada sisi klien tanpa menunggu konfirmasi server. Namun, implementasi tanpa pengaman konkurensi dapat memicu mutation storm ketika pengguna melakukan aksi repetitif dalam hitungan milidetik. Artikel ini membedah postmortem insiden produksi pada aplikasi Next.js: bagaimana lonjakan mutasi melumpuhkan database pool, deteksi melalui observability, mitigasi cepat tanpa redeploy, dan arsitektur pencegahan permanen.

Kronologi dan Sinyal Observability Awal

Insiden bermula ketika fitur interaktif (seperti bookmark, voting, atau toggle status) dirilis menggunakan Optimistic UI. Pengguna mengeklik tombol aksi lima kali secara berturut-turut dalam rentang waktu kurang dari satu detik. Sisi klien menembakkan lima mutasi HTTP/Server Action paralel ke backend.

Sistem telemetri memicu serangkaian alarm otomatis akibat anomali metrik berikut:

  • Lonjakan p99 Latency: Latensi p99 endpoint mutasi melonjak drastis dari 45ms menjadi lebih dari 8.500ms akibat antrean antarthread pemrosesan.
  • DB Connection Pool Exhausted: Metrik koneksi database (PgBouncer/Prisma pool) mencapai batas maksimum (100% active connections). Muncul error log: Timed out fetching a new connection from the pool.
  • Lonjakan Error Rate 500: Server mulai mengembalikan status code 500 akibat timeout kueri database dan cascaded failure pada dependensi downstream.
# Contoh kueri Prometheus untuk mendeteksi saturasi pool dan mutasi berlebih
expr: sum(rate(http_requests_total{handler="/api/mutate", status=~"5.."}[1m])) 
      / sum(rate(http_requests_total{handler="/api/mutate"}[1m])) * 100 > 5

expr: pg_stat_activity_count{state="active"} / pg_settings_max_connections * 100 > 85

Triage Cepat dan Mitigasi Darurat

Saat insiden berlangsung, rollback deployment penuh memerlukan waktu pipeline build (5-10 menit) yang memperparah downtime. Dua langkah mitigasi darurat diambil untuk menghentikan degradasi sistem:

1. Rate Limiting di Lapisan Gateway

Proteksi langsung diterapkan pada API Gateway (Cloudflare WAF / Nginx / Reverse Proxy) dengan membatasi request mutasi per IP atau per User Session. Mutasi berlebih langsung dipotong dengan respons 429 Too Many Requests sebelum menyentuh aplikasi.

# Potongan konfigurasi Nginx emergency rate limit
limit_req_zone $binary_remote_addr zone=mutation_limit:10m rate=2r/s;

location /api/mutations/ {
    limit_req zone=mutation_limit burst=3 nodelay;
    proxy_pass http://upstream_backend;
}

2. Kill Switch via Feature Flag

Backend membaca konfigurasi feature flag dinamis dari runtime cache (Redis). Ketika flag ENABLE_OPTIMISTIC_MUTATION dimatikan, handler memutus eksekusi asinkronus dan mewajibkan fallback ke synchronous locking atau menonaktifkan tombol aksi secara terpusat tanpa deployment kode baru.

Root Cause Analysis: Out-of-Order Execution

Akar masalah utama adalah ketiadaan serialisasi dan konkurensi pada mutasi asinkron:

  1. Race Condition Jaringan: Permintaan #1 (state: ON) dan Permintaan #2 (state: OFF) dikirim nyaris bersamaan. Permintaan #2 diproses lebih cepat oleh database daripada Permintaan #1.
  2. Out-of-order Execution: Database mengeksekusi Permintaan #1 terakhir. Hasil akhir di database adalah ON, sementara UI klien menampilkan status OFF (sesuai aksi klik terakhir). Terjadi divergensi data persisten.
  3. Resource Contention: Setiap mutasi membuka transaksi database baru yang memicu penguncian baris (row locking) pada entitas yang sama, mengakibatkan antrean transaksi dan kehabisan pool koneksi.

Tindakan Pencegahan Permanen

Untuk mengeliminasi mutation storm secara struktural, tiga mekanisme perlindungan wajib diimplementasikan:

1. Kontrak Idempotency-Key

Setiap mutasi dari Optimistic UI wajib menyertakan header Idempotency-Key unik (berbasis hash dari payload dan ID entitas). Backend memanfaatkan distributed cache (Redis) untuk menolak atau mengabaikan mutasi in-flight yang identik.

import { Redis } from "@upstash/redis";

const redis = new Redis({ /* credentials */ });

export async function handleMutation(req: Request) {
  const idempotencyKey = req.headers.get("Idempotency-Key");
  if (!idempotencyKey) {
    return new Response("Missing Idempotency-Key", { status: 400 });
  }

  // ponytail: Gunakan lock TTL pendek; ganti ke redlock bila multi-cluster.
  const acquired = await redis.set(`lock:${idempotencyKey}`, "1", {
    nx: true,
    ex: 5, // Lock berlaku 5 detik
  });

  if (!acquired) {
    return new Response("Concurrent mutation in progress", { status: 409 });
  }

  try {
    // Jalankan logika transaksi database
    return new Response(JSON.stringify({ success: true }), { status: 200 });
  } finally {
    await redis.del(`lock:${idempotencyKey}`);
  }
}

2. Client-side Concurrency Control

Klien tidak boleh membiarkan aksi paralel tanpa kendali. Gunakan AbortController untuk membatalkan permintaan jaringan sebelumnya yang belum selesai, atau manfaatkan primitive UI seperti status isPending dari hook React untuk mendisabel tombol sementara mutasi berlangsung.

3. Konfigurasi Alerting Proaktif

Konfigurasikan alert pada APM (Datadog/Grafana) dengan ambang batas ketat:

  • Trigger alert Warning bila rasio mutasi per user melebihi 10 request dalam 5 detik.
  • Trigger alert Critical bila sisa koneksi pool database < 15% selama lebih dari 30 detik berkelanjutan.