Website paling sering down itu justru disaat paling dibutuhkan. Pas lagi viral, pas lagi promo atau pas calon customer lagi niat beli. Ironis, karena momen itu harusnya jadi panen, bukan panik.
Kenapa Ini Sering Terjadi
Kebanyakan web murah, bahkan yang kelihatannya bagus dari luar itu jalan di infrastruktur yang numpuk. Satu server dipakai bareng-bareng sama ratusan, kadang ribuan website lain, tanpa batas yang jelas antar satu sama lain. Selama semuanya sepi, nggak ada masalah. Begitu salah satu situs kena lonjakan traffic, atau parahnya kena serangan, website lain yang numpuk di server yang sama ikut kena imbas. Bukan karena web kamu yang bermasalah, tapi karena tetangga sebelah lagi rebutan resource yang sama.
Ini bukan cuma soal harga murah. Banyak yang mikir "yang penting saya bayar mahal, pasti amanlah." Padahal harga mahal nggak otomatis berarti arsitekturnya lebih siap. Kalau desainnya sama-sama numpuk tanpa isolasi resource per situs, mau bayar berapa pun, pas traffic naik tiba-tiba, hasilnya sama yaitu lemot atau down. Yang membedakan bukan angka di invoice, tapi apakah sistemnya dirancang buat kondisi ramai sejak awal, atau cuma ditambal pas udah kejadian.
Bagaimana JadiWeb Memastikan Ini Nggak Terjadi
Kami nggak mau cuma bilang "sistem kami aman" tanpa bukti. Salah satu bagian dari proses produksi di JadiWeb adalah stress test — kami sengaja mensimulasikan banyak pengunjung sekaligus buat lihat di titik mana sistem mulai goyang, sebelum itu kejadian beneran di depan calon customer klien kami.
Test terakhir kami jalankan dengan 100 pengunjung virtual bersamaan, sustained selama 5,5 menit. Bukan hanya lonjakan sesaat, tapi tekanan yang terus-menerus. Hasilnya: 7.688 request diproses, 100% berhasil, 0% gagal. Response time rata-rata 13,69ms, dan 95% dari seluruh request selesai di bawah 17,37ms. Bahkan request paling lambat sekalipun masih jauh di bawah batas yang kami tetapkan sebagai standar minimum.
Tapi ada satu hal yang jujur perlu kami akui, sistem kami nggak menyalakan semua website 24 jam penuh. Tiap website dijalankan di unit pemroses terpisah ("worker") yang otomatis dimatikan kalau lagi nggak ada yang akses, biar resource server nggak kebuang percuma buat website yang lagi sepi. Konsekuensinya, begitu ada pengunjung baru setelah worker itu "tidur", ada jeda buat menyalakannya lagi.
Awalnya jeda ini cukup terasa dari pengukuran kami, worker butuh sekitar 1 sampai 1,6 detik buat startup sampai siap melayani request. Kami nggak berhenti di angka itu. Setelah dioptimasi, waktu startup ini berhasil ditekan sampai sekitar 650ms — dan itu kemungkinan besar sudah mendekati batas fisik dari proses startup itu sendiri, bukan lagi soal kode yang belum efisien.
Tapi 650ms tetap 650ms. Kalau ini dialami tiap pengunjung, itu masih jeda yang kerasa. Makanya kami nggak berhenti cuma di optimasi startup — kami taruh Varnish sebagai lapisan cache di depan seluruh sistem. Alih-alih tiap request harus nunggu worker menyala, mayoritas pengunjung sebenarnya dilayani langsung dari cache jadi nggak perlu nyentuh worker sama sekali. Worker cuma dibangunkan kalau memang ada permintaan yang belum ada di cache, dan begitu satu kali kena cache, pengunjung berikutnya nggak akan ngerasain jeda itu lagi.
Kenapa Ini Penting Buat Bisnis, Bukan Cuma Developer
Semua penjelasan tadi mungkin kedengaran teknis, tapi dampaknya sangat bisnis. Bayangkan toko online kamu tiba-tiba jadi viral pagi ini, atau klinik kamu masuk berita dan orang rame-rame cari nomor booking. Momen itu cuma datang sekali, dan kalau website down atau lemot pas orang lagi niat, mereka nggak nunggu tapi mereka pindah ke tab lain, atau ke kompetitor.
Ini bedanya downtime di dunia nyata dibanding di atas kertas. Buat developer, downtime itu angka di dashboard monitoring. Buat pemilik bisnis, itu customer yang hilang di detik paling krusial. Customer yang udah niat beli, udah niat booking, tapi keburu kabur karena halaman nggak kebuka-buka.
Makanya angka uptime yang kami jaga bukan sekadar target di atas kertas. Itu hasil dari keputusan arsitektur yang kami bahas tadi yaitu isolasi tiap website di worker terpisah, efisiensi lewat auto-sleep, optimasi startup time, dan cache layer yang menutup celah boot time. Semuanya dirancang biar satu hal ini terjamin: pas bisnis kamu lagi butuh website-nya bekerja paling keras, di situlah sistemnya justru paling siap.
Penutup
Ini yang membedakan cara kami kerja dari agency kebanyakan. Website bukan cuma soal tampilan yang bagus pas demo, tapi soal apakah dia masih berdiri pas beneran dibutuhkan. Infrastruktur bukan hal yang kami pikirkan belakangan setelah ada masalah tapi itu bagian dari sistem produksi sejak hari pertama.
Makanya kami nyebut diri sistem produksi, bukan vendor. Vendor selesai kerja pas website online. Sistem produksi terus jalan, terus diuji, dan terus dipastikan siap, bahkan buat skenario yang belum tentu kamu alami hari ini, tapi bisa aja terjadi besok.
Kalau kamu penasaran gimana proses produksi website di JadiWeb bekerja dari awal sampai akhir, bisa dibaca di halaman Proses Produksi kami.
