Apa yang Jebol Saat Peluncuran Kamu Benar-Benar Berhasil

Sistem yang setahun ini jalan tenang bisa jebol di empat menit pertama sebuah campaign. Bukan karena dibangun dengan buruk, tapi karena dia belum pernah ditanya pertanyaan sebesar ini.

Ini lima jawaban yang biasanya salah, kira-kira sesuai urutan kemunculannya.

1. Query yang tidak ada yang memberi index

Satu pencarian database, jalan di setiap kali halaman dibuka, menyapu seluruh tabel. Di trafik normal biayanya milidetik yang tidak terasa. Di lonjakan, dia jadi antrean yang harus ditunggu semua hal lainnya.

Ini penyebab tunggal paling umum sistem jatuh di hari peluncuran, dan biasanya paling murah dibetulkan begitu kamu tahu query mana yang bermasalah.

2. State yang tinggal di memori satu server

Sesi, keranjang, atau form yang sedang diisi, disimpan di mesin yang melayani permintaan pertama. Menambah server justru memperburuk, bukan memperbaiki: separuh penggunamu diarahkan ke server yang tidak pernah mengenal mereka.

3. Pihak ketiga yang membatasi kamu

Payment gateway, penyedia SMS, atau API peta punya batas, dan lonjakan adalah saat kamu menyentuhnya. Yang lebih buruk, kegagalannya sering tanpa suara — permintaannya tidak kembali, dan sistemmu menunggu.

Yang bisa dilakukan

Ketahui batasnya sebelum tanggalnya, antrekan permintaan alih-alih mengirim semuanya sekaligus, dan putuskan sejak awal apa yang dilihat pengguna kalau pihak ketiga menolak. Pesan yang jelas lebih baik daripada loading yang tidak pernah selesai.

4. Auto-scaling yang datangnya terlambat

Auto-scaling bereaksi terhadap beban, dan menyalakan instance baru butuh beberapa menit. Lonjakan campaign selesai lebih cepat dari itu. Saat kapasitas tambahannya siap, kerusakannya sudah terjadi dan trafiknya sudah pergi.

Untuk jam mulai yang sudah diketahui, panaskan kapasitasnya lebih dulu, jangan menambah saat kejadian. Scaling reaktif itu untuk pertumbuhan yang bertahap, bukan untuk lonjakan.

5. Queue yang aman kalau per menit

Pekerjaan latar yang diukur untuk sepuluh job per menit tidak selamat di sepuluh per detik. Website-nya tetap hidup, dan itu yang membuat masalah ini mudah terlewat, tapi email konfirmasinya datang empat jam kemudian dan order-nya menumpuk belum diproses.

Cara menemukan punyamu sebelum pelanggan menemukannya

1. Salin produksi, termasuk jumlah data yang realistis — menguji ke database kosong tidak membuktikan apa pun
2. Uji beban di angka yang kamu perkirakan, lalu di dua kali angka itu
3. Betulkan hal pertama yang jebol, lalu jalankan ujinya lagi — sumbatan kedua selalu bersembunyi di belakang yang pertama
4. Ulangi sampai batas atasnya nyaman di atas puncak yang kamu perkirakan
5. Tuliskan siapa yang berjaga di hari-H dan apa yang memicu rencana mundur

Perkirakan tiga putaran. Perkirakan sumbatan pertamanya berupa hal yang tidak ada yang menduga. Itu hasil normal dari mengerjakan ini dengan benar, bukan tanda ada yang dibangun dengan buruk.

Kalau peluncuran kamu minggu depan

Masih ada versi yang berguna: temukan satu sumbatan terburuk, taruh antrean di depan pintu masuknya, dan kurangi cakupan di tempat yang bisa dikurangi. Yang tidak bisa dijanjikan siapa pun dengan jujur dalam seminggu adalah hasil akhirnya.

Cara kami menjalankannya ada di halaman platform campaign trafik tinggi, dan bentuk nyatanya di sebuah campaign ada di studi kasusnya.