11.11 baru saja lewat, 12.12 tinggal tiga minggu lagi, dan kalau Anda menjalankan bisnis apa pun dengan halaman checkout di Indonesia, Anda pasti sudah tahu: scaling untuk peak traffic bukan latihan teoretis. Ini adalah live-fire drill yang membongkar dalam satu akhir pekan apa yang selama sebulan traffic normal justru tersembunyi selama bertahun-tahun. Saya sudah cukup sering duduk di war room semacam ini untuk hafal polanya di luar kepala, dan biasanya bukan bagian yang dikhawatirkan semua orang.

Semua orang bersiap untuk kemungkinan server down. Itu masalah yang mudah, dan sejujurnya sudah diselesaikan kebanyakan tim dengan auto-scaling dasar. Kegagalan yang sebenarnya menjatuhkan sebuah event sale justru bersembunyi di tempat yang kurang kentara: antrean callback pembayaran, sinkronisasi stok antar-channel, dan asumsi bahwa "berjalan lancar di 3x traffic normal" berarti akan tetap lancar di 15x.

Berikut apa yang pernah saya lihat rusak, sudah dianonimkan, dan apa yang benar-benar memperbaikinya.

Server Jarang Jadi yang Down Duluan

Kebanyakan bisnis terlalu berinvestasi pada raw compute scaling untuk peak traffic dan kurang berinvestasi pada segala hal di hilirnya, di belakang web server. Sebuah retail chain di Tangerang yang menjalankan situs e-commerce sendiri menghabiskan berminggu-minggu sebelum 11.11 untuk upgrade tier server, dengan asumsi itulah risikonya. Halaman checkout mereka bertahan baik-baik saja di bawah beban. Yang rusak justru webhook callback dari payment gateway, yang diterima server dengan sempurna tapi kemudian antre di belakang backlog konfirmasi order yang belum diproses, karena queue worker masih diukur untuk volume hari normal.

Pelanggan berhasil membayar. Order mengambang tanpa kejelasan selama dua puluh menit sebelum email konfirmasi terkirim. Tim support kebanjiran pesan "apakah pembayaran saya berhasil", yang hasil akhirnya lebih buruk daripada halaman lambat, karena terlihat seperti penjualan yang hilang padahal sebenarnya tidak.

Pelajaran: scale queue worker dan background job processor Anda lebih dulu daripada web tier, bukan belakangan.

Antrean Callback Pembayaran Adalah Hal Pertama yang Harus Di-load-test

Payment gateway (Midtrans, Xendit, dan sejenisnya) mengirim callback asinkron ketika pembayaran selesai. Pada traffic normal, callback ini datang perlahan dan langsung diproses. Pada peak traffic, callback datang secara beruntun, dan jika pemrosesan Anda bersifat sinkron atau single-threaded, backlog terbentuk dengan cepat dan terus menumpuk.

Sebelum event sale besar apa pun, lakukan load test khusus untuk endpoint callback secara terpisah, bukan hanya alur checkout. Simulasikan seribu callback dalam enam puluh detik dan amati apa yang terjadi pada waktu pemrosesan. Kalau tidak sub-detik pada volume tersebut, itulah bottleneck Anda, bukan web server Anda.

Sinkronisasi Stok Rusak Diam-diam, Lalu Menjadi Mahal

Kegagalan berulang kedua: sinkronisasi stok antara storefront, sistem gudang, dan channel marketplace mana pun (Tokopedia, Shopee) yang juga Anda gunakan untuk berjualan. Pada traffic normal, job sync yang berjalan setiap beberapa menit sudah cukup cepat. Pada peak traffic, jarak antara "sync bilang stok 5" dan "stok aktual 0" melebar karena order masuk lebih cepat daripada interval sync.

Ini menghasilkan jenis kegagalan peak-season yang paling buruk: overselling. Anda menerima pembayaran untuk barang yang sebenarnya tidak ada, dan sekarang Anda harus mengeluarkan refund dan pesan permintaan maaf di akhir pekan dengan visibilitas tertinggi sepanjang tahun. Salah satu partner retail yang berdekatan dengan multifinance yang pernah saya tangani mengalami persis ini: sync mereka berjalan setiap lima menit, cukup baik untuk 200 order/jam, tapi bencana untuk lonjakan 2.000 order/jam yang mereka terima di jam pertama flash sale.

Perbaikan yang murah: khusus untuk 20-30 SKU terlaris Anda, alihkan ke pengurangan stok real-time pada saat order masuk, bukan sync periodik, meskipun sisa katalog Anda tetap memakai sync yang lebih lambat. Anda tidak perlu membangun ulang seluruh arsitektur inventory, cukup segelintir item yang memang akan benar-benar habis terjual.

"Berjalan Lancar di 3x" Bukan Berarti Lancar juga di 15x

Pemikiran linear adalah jebakannya. Tim menguji pada beban moderat dan berasumsi sistem akan scale secara linear di luar itu. Kenyataannya jarang begitu, karena bottleneck berpindah tempat. Database yang menangani 3x beban dengan baik-baik saja bisa mentok connection pool limit di 10x. Cache yang menyerap read load dengan baik di 5x mungkin mulai mengalami cache miss yang cukup signifikan di 15x sehingga database di baliknya kena hit langsung.

Load test pada multiplier tertinggi yang bisa Anda justifikasi secara masuk akal dari angka peak tahun lalu, bukan multiplier yang nyaman untuk diuji. Kalau Anda tidak punya angka tahun lalu, asumsikan peak adalah 10-20x rata-rata harian Anda untuk jam spesifik saat flash sale berlangsung, bukan rata-rata sepanjang hari.

Persiapan Murah yang Benar-benar Berdampak

Anda tidak perlu overhaul infrastruktur enam bulan sebelum event sale berikutnya. Berikut langkah dengan leverage tertinggi dan biaya terendah:

  • Load-test khusus jalur callback pembayaran dan konfirmasi order, bukan hanya homepage dan UI checkout.
  • Pindahkan SKU terlaris Anda ke pengurangan stok real-time, biarkan long tail tetap pada sync periodik.
  • Siapkan staging environment sementara yang mencerminkan production untuk gladi resik seminggu sebelum event. Kalau Anda belum punya, ini layak dibenahi terlepas dari musimnya.
  • Pre-scale queue worker dan connection pool database secara manual sebelum jendela event berlangsung, jangan hanya mengandalkan auto-scaling untuk bereaksi tepat waktu, karena auto-scaling punya lag sementara lonjakan peak traffic seringkali nyaris instan.
  • Siapkan rencana rollback untuk kasus overselling stok: template komunikasi pelanggan yang sudah ditulis lebih dulu dan proses refund yang jelas, sehingga kalau ini benar-benar terjadi, waktu respons dihitung dalam menit, bukan jam.

Kesimpulan Praktis

Scaling untuk peak traffic dimenangkan atau dikalahkan di bagian stack yang tidak pernah di-screenshot siapa pun: antrean callback, job sync, batas connection pool. Uji bagian-bagian itu secara spesifik, pada multiplier yang realistis, sebelum 12.12 berikutnya atau event sale besar mana pun. Bisnis yang keluar dari akhir pekan semacam ini tanpa luka bukanlah yang punya budget server terbesar, melainkan yang menemukan bottleneck sebenarnya saat gladi resik, bukan saat live, di depan pelanggan yang pembayarannya sudah terlanjur diambil.