Hai, Software Engineers!

Pernahkah Anda merasa kesal saat situs pendaftaran CPNS tiba-tiba tidak bisa diakses, atau saat layar Anda terus-terusan menampilkan 502 Bad Gateway ketika sedang ‘war’ tiket konser musisi favorit? Di saat-saat seperti itu, kita mungkin bertanya-tanya: “Masa perusahaan sebesar ini tidak bisa bikin server yang kuat?”

Di era modern, ada sebuah ilusi pemasaran yang sangat populer di dunia teknologi: fitur “One-Click Deploy” atau rilis aplikasi dengan satu klik. Fitur ini membuat proses peluncuran aplikasi terlihat sangat mudah, seolah-olah siapa saja bisa membuat aplikasi global dalam hitungan detik. Namun, kenyataannya, membuat sebuah aplikasi berfungsi dengan baik di laptop seorang pembuat kode (programmer) sangatlah jauh berbeda dengan memastikan aplikasi tersebut tetap hidup saat diserbu ratusan ribu hingga jutaan pengunjung secara bersamaan.

Ibaratnya seperti ini: memasak nasi goreng untuk makan malam Anda sendiri di dapur (lingkungan pengembangan lokal) itu mudah. Namun, tiba-tiba Anda harus memasak untuk 10.000 orang kelaparan yang mendobrak masuk ke dapur Anda pada detik yang sama. Resep yang sama tidak akan lagi bekerja; Anda butuh manajemen logistik, puluhan koki, dan ruang yang luas. Di dunia perangkat lunak, inilah yang disebut dengan seni skalabilitas.

Berikut adalah beberapa alasan mengapa memastikan aplikasi tidak down tetap membutuhkan “keringat” dan kejeniusan para insinyur manusia, bukan sekadar mengandalkan teknologi otomatis:

  1. Penambahan Server Otomatis (Auto-Scaling) Bukanlah Sihir Banyak yang mengira bahwa saat lalu lintas pengunjung melonjak, sistem cloud (komputasi awan) akan secara magis dan instan menambahkan server baru. Faktanya, sistem otomatis ini bersifat reaktif. Saat mendeteksi server mulai kepanasan, sistem butuh waktu—bisa sampai lima menit—untuk menyalakan server baru, memuat sistem operasi, dan menyalin aplikasi. Sayangnya, dalam skenario seperti flash sale, jutaan pengunjung bisa masuk hanya dalam 60 detik. Dalam jeda lima menit yang krusial itu, server lama sudah keburu tenggelam dan aplikasi pun lumpuh. Insinyur manusia harus memprediksi dan memanaskan mesin-mesin ini secara manual sebelum badai pengunjung datang.
  2. Serangan Jantung pada Basis Data (Database) Jika server web adalah otot aplikasi, basis data adalah jantungnya. Kelumpuhan aplikasi sering kali bukan karena server web yang lemah, melainkan karena antrean koneksi di basis data yang sudah mentok. Contoh menarik pernah dialami oleh Gojek di masa awal pertumbuhannya. Mereka memiliki fitur di mana 1 pesanan disiarkan langsung ke 200 sopir terdekat. Saat pesanan sedang tinggi, fitur ini justru menciptakan ratusan ribu panggilan antrean secara paralel yang mencekik basis data utama, membuat layanan sering lumpuh. Memperbaiki hal ini tidak bisa diselesaikan dengan sekadar menambah server; insinyur harus membongkar dan menulis ulang logika kode tersebut.
  3. Misteri 502 Bad Gateway dan Batasan Jaringan Saat web sedang kelebihan beban, sering muncul tulisan galat seperti 502 Bad Gateway atau 504 Gateway Timeout. Ini biasanya terjadi karena lalu lintas internet Anda melewati “satpam” gerbang depan (seperti proksi Cloudflare) yang memiliki batas waktu tunggu maksimal, misalnya 120 detik. Jika server asli terlalu sibuk mengurus antrean dan tidak merespons dalam 120 detik, satpam ini akan memutus koneksinya secara paksa.

Selain itu, jaringan tingkat global sangat sensitif terhadap kesalahan kecil. Pada bulan November 2025, sebuah kesalahan konfigurasi izin pangkalan data yang sepele secara tidak sengaja melipatgandakan ukuran berkas keamanan. Akibatnya, perangkat lunak jaringan gagal memproses berkas raksasa tersebut, yang berujung pada lumpuhnya 20% lalu lintas web dunia, termasuk bursa kripto.

  1. Pola Pemutus Sirkuit (Circuit Breaker) Untuk mencegah satu fitur yang rusak menumbangkan seluruh aplikasi, insinyur menggunakan teknik yang disebut Circuit Breaker. Persis seperti sekring listrik di rumah Anda. Jika layanan pengecekan ongkos kirim sedang bermasalah dan lelet, sekring digital ini akan “memutus” sementara jalur ke layanan tersebut. Alhasil, pengguna mungkin tidak bisa melihat ongkos kirim sejenak, namun aplikasi utama tidak ikut mati dan pengguna masih bisa melihat-lihat produk yang lain.
  2. Ruang Perang (War Room) dan Dedikasi Manusia Ketika aplikasi raksasa menghadapi acara besar, tidak ada sistem otomatis yang dibiarkan berjalan sendiri. Perusahaan teknologi membentuk tim khusus bernama Site Reliability Engineering (SRE) dan DevOps yang berkumpul di “Ruang Perang” (War Room) virtual untuk memantau setiap denyut nadi aplikasi.

Sebagai contoh di lanskap teknologi Indonesia, ketika Tokopedia mengadakan ajang televisi dan Flash Sale raksasa, mereka menggunakan teknologi canggih dari Google (GKE) untuk menampung lonjakan lalu lintas yang naik drastis. Namun, yang membuat sistem ini brilian adalah kemampuan insinyurnya untuk menyusutkan kembali kapasitas server hingga 30 kali lipat secara instan begitu acara selesai, sehingga perusahaan bisa menghemat biaya operasional secara masif.

Mengeklik tombol “Deploy” dan melihat aplikasi Anda tayang di internet adalah hal yang sangat mudah dan menyenangkan. Namun, mendesain aplikasi agar bisa menahan terjangan jutaan manusia yang tak sabaran, menjaga agar biaya server tidak membuat perusahaan bangkrut, dan memastikan satu eror kecil tidak menghancurkan keseluruhan sistem, adalah murni sebuah karya seni dan sains yang lahir dari keringat serta logika tajam para insinyur di balik layar.

 

References

https://appscrip.com/blog/inside-tokopedia-tech-stack-and-infrastructure/

https://www.gojek.io/blog/how-gojek-manages-1-million-drivers-with-12-engineers-part-1

https://www.gojek.io/blog/how-gojek-manages-1-million-drivers-with-12-engineers-part-2-2

https://martinfowler.com/bliki/CircuitBreaker.html

https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker