Setiap tahun sekitar 11.11, situs web seseorang mati pada saat yang paling penting. Skalabilitas sistem mega sale adalah pelajaran tahunan yang sangat umum mengenai masalah yang dihadapi setiap bisnis pada skalanya masing-masing, bahkan bisnis yang tidak pernah menjalankan kampanye Harbolnas: apa yang terjadi jika semua orang hadir sekaligus. Sistem yang bekerja dengan baik pada hari Selasa normal dan gagal pada hari yang diperlukan untuk bertahan bukanlah kegagalan yang jarang terjadi, ini adalah hasil default karena tidak pernah menguji pada hari yang penting.

Saya telah menghabiskan 11,11 minggu di kedua belah pihak, membangun sistem yang dimaksudkan untuk bertahan dari lonjakan tersebut dan dipanggil setelahnya untuk menjelaskan mengapa ada yang tidak melakukannya. Fisikanya sama, baik Anda adalah platform e-niaga nasional atau bisnis ritel yang terdiri dari lima orang yang menjalankan satu promosi besar. Hanya skalanya yang berubah.

Identifikasi satu jalur yang menghasilkan uang

Selama penjualan besar-besaran, sebagian besar fungsi sistem menjadi tidak relevan selama beberapa jam kritis. Tidak ada yang peduli jika widget "item yang baru dilihat" lambat. Tidak ada yang peduli jika halaman pengaturan akun memerlukan dua detik ekstra untuk dimuat. Yang penting adalah satu jalur sempit: telusuri atau cari barang yang didiskon, tambahkan ke keranjang, periksa, bayar.

Satu-satunya kegagalan skalabilitas yang paling umum bukanlah kegagalan sistem secara total, melainkan jalur kritis yang kekurangan sumber daya karena semua hal lainnya masih berjalan normal. Mesin rekomendasi yang menjalankan kueri mahal di latar belakang, piksel pemasaran yang aktif pada setiap pemuatan halaman, dasbor admin yang dibiarkan terbuka dan disegarkan oleh seseorang, semua ini bersaing untuk mendapatkan koneksi database dan kapasitas server yang sama dengan alur pembayaran yang benar-benar menghasilkan pendapatan.

Perbaikan sebelum penjualan besar-besaran bukanlah "membuat segalanya lebih cepat", melainkan "mengidentifikasi dua atau tiga layar yang menghasilkan uang dan melindunginya secara khusus", bahkan jika itu berarti menonaktifkan atau menurunkan segalanya untuk sementara.

Checkout hampir selalu menjadi hambatan

Di hampir setiap insiden skalabilitas yang telah saya ulas, titik kegagalan sebenarnya adalah proses checkout, khususnya proses pembayaran dan penurunan inventaris yang terjadi pada saat yang sama untuk jumlah pengguna yang jauh lebih besar secara bersamaan dibandingkan hari-hari biasa. Dua pola kegagalan berulang:

  1. Kondisi perlombaan inventaris, dua pelanggan melihat "1 tersedia", keduanya menambahkan ke keranjang, keduanya berupaya membayar, dan sistem menjual terlalu banyak atau mengunci dalam upaya menyelesaikan konflik pada beban yang tidak dirancang untuknya.
  2. Waktu tunggu gateway pembayaran habis secara berjenjang, respons yang sedikit lebih lambat dari biasanya dari gateway pembayaran, biasanya tidak terlihat, menjadi antrean koneksi yang ditahan ketika ribuan kasir sedang terbang secara bersamaan, dan antrean itu sendiri menjadi pemadaman.

Keduanya dapat dipecahkan, namun hanya jika diuji pada volume realistis sebelumnya, tidak ditemukan secara langsung. Alur pembayaran yang belum pernah diuji bebannya pada sepuluh kali lalu lintas normal, untuk tujuan skalabilitas, adalah sistem yang tidak diketahui, bukan sistem yang dikenal baik, yang kebetulan gagal.

Caching adalah pahlawan yang tidak menarikSatu-satunya perbaikan dengan leverage tertinggi untuk sebagian besar masalah skalabilitas mega-penjualan adalah cache agresif atas apa pun yang tidak perlu dihitung baru untuk setiap pengunjung: halaman daftar produk, harga, spanduk promosi, penghitungan stok dengan sedikit penundaan (detik, bukan waktu nyata, biasanya baik-baik saja untuk penelusuran, bahkan jika pembayaran itu sendiri memerlukan keakuratan). Melayani halaman yang di-cache ke seratus ribu pengunjung penjelajahan, dibandingkan memasukkan database ke setiap halaman, sering kali merupakan perbedaan besar antara situs yang dapat menampung dan yang tidak.

Ini kedengarannya mendasar karena memang demikian. Sebagian besar insiden skalabilitas yang saya ulas setelah faktanya bukan disebabkan oleh kegagalan teknis yang eksotik, melainkan disebabkan oleh database yang melakukan pekerjaan berulang-ulang dan dapat di-cache pada volume yang tidak pernah diukur, karena tidak ada yang menyiapkan cache untuk halaman tertentu yang akan mengalami lonjakan.

Kapasitas yang belum teruji adalah fiksi

"Kami seharusnya baik-baik saja, kami memiliki server yang kuat" adalah kalimat yang saya dengar tepat sebelum hampir setiap insiden skalabilitas. Kapasitas yang belum diuji bebannya terhadap simulasi realistis lalu lintas mega-sale hanyalah dugaan yang dibuat seperti sebuah rencana. Pengujian yang tepat menyimulasikan pola sebenarnya yang diharapkan, lonjakan tiba-tiba pada saat penjualan kilat dibuka, bukan peningkatan bertahap, karena pola lonjakan tiba-tiba itulah yang sebenarnya merusak sistem yang menangani pertumbuhan bertahap dengan baik.

Untuk bisnis kecil atau menengah yang menjalankan promosi besar untuk pertama kalinya, hal ini tidak memerlukan pengaturan pengujian beban yang mahal. Hal ini memerlukan, paling tidak, dengan sengaja melakukan simulasi ledakan pesanan secara bersamaan terhadap salinan pementasan sistem seminggu sebelum kejadian sebenarnya, dan memperhatikan apa yang rusak terlebih dahulu. Sesuatu akan terjadi. Lebih baik menemukannya berdasarkan pesanan palsu daripada pelanggan sungguhan.

Fisika yang sama berlaku pada skala usaha kecil

Anda tidak perlu menjadi platform nasional untuk menerapkan pelajaran ini. Sebuah jaringan ritel yang menjalankan promosi besar-besaran di akhir tahun, atau sebuah bisnis makanan yang memasang penawaran viral, menghadapi hal yang sama dalam jumlah yang lebih kecil: sistem pemesanan WhatsApp yang bekerja dengan baik pada dua puluh pesanan per jam dapat terhenti total pada dua ratus, sistem pemesanan yang belum pernah diuji melebihi volume harian normal dapat terhenti saat promosi mencapai lonjakan. Lihat bengkel otomotif mengakhiri kekacauan yang terjadi untuk gambaran terkait tentang apa yang terjadi ketika sistem yang dibangun untuk hari-hari tenang bertemu dengan hari yang tidak sesuai dengan ukurannya.

Persiapannya secara proporsional sama: ketahui satu jalur kritis Anda, lindungi, simpan apa yang bisa di-cache, dan uji pada volume yang lebih tinggi dari yang Anda harapkan sebelum hari penting, bukan setelahnya.

Bawa pulang

Skalabilitas sistem penjualan besar, baik saat Anda bersiap untuk 11.11 atau promosi akhir tahun Anda sendiri, terbagi dalam tiga disiplin: lindungi satu jalur yang menghasilkan uang dan biarkan yang lainnya menurun terlebih dahulu, simpan cache secara agresif sehingga database Anda tidak mengulangi pekerjaan untuk setiap pengunjung, dan uji pada volume puncak yang realistis sebelum hari sebenarnya, bukan selama hari itu. Perusahaan-perusahaan yang turun ke publik setiap 11.11 bukannya tidak beruntung, mereka adalah perusahaan-perusahaan yang memperlakukan kapasitas sebagai angka pada lembar spesifikasi dan bukan sebagai klaim yang memerlukan pengujian.