Dasbor menunjukkan empat puluh instance berjalan, naik dari dua belas instance pagi ini. Autoscaler melakukan tugasnya: mendeteksi lonjakan latensi dan menambahkan sumber daya komputasi. Namun, latensi justru memburuk, bukan membaik. Pengguna membayar tiga kali lebih banyak untuk komputasi namun menerima produk yang lebih lambat. Di balik semua instance tersebut, ada satu titik yang menjadi tempat antrian bersama, dan setiap instance baru hanya memperpanjang antrian tersebut. Scaling horizontal melipatgandakan pekerjaan yang tidak perlu dikoordinasi, tetapi saat pekerjaan harus berkoordinasi, lebih banyak instance justru memperlambat sistem. Amdahl merumuskan hukumnya pada tahun 1967: fraksi serial dari sebuah tugas menetapkan batas keras seberapa cepat sistem dapat berjalan, terlepas dari seberapa besar sumber daya paralel yang ditambahkan. Neil Gunther memperluas konsep ini melalui Universal Scalability Law: pada suatu titik, biaya koordinasi antar node akan membelokkan kurva performa kembali ke bawah. Menambahkan kapasitas justru mengurangi throughput. Batas ini tidak ditetapkan oleh autoscaler, dan tidak akan bergeser olehnya. Batas tersebut sudah ditentukan jauh sebelum pagi ini, di sebuah ruang rapat, oleh orang yang memutuskan di mana state disimpan dan siapa yang harus mengaksesnya secara bersamaan. Sekarang, layanan diserahkan kepada sekelompok agen. Hasilnya terlihat seperti sistem yang dirancang untuk skala: handler stateless, repositori rapi, pengujian otomatis, dan penyebaran canary yang berjalan baik pada satu persen trafik. Setiap pintu gerbang yang dipercaya mengatakan "kirim". Namun, bottleneck sebenarnya tetap ada, tersembunyi dalam desain, karena masalahnya bukan pada kode, melainkan pada bentuk arsitektur.
Kesalahan ini tidak dapat terdeteksi dengan hanya membaca diff kode. Identifikasi state yang paling banyak diakses sebelum memilih kerangka kerja. Di mana state yang sering diakses berada, dan permintaan mana yang menyentuhnya secara bersamaan? Jawaban atas pertanyaan ini harus diungkapkan sebelum seorang pun membuka editor. Alat apa pun yang digunakan selalu merupakan turunan dari jawaban tersebut. Awalnya diterbitkan di https://imacto.com/writing/scale-is-a-design-not-a-dial, ditulis dengan Claude Opus 4.8.
Bagi tim di Indonesia, pola ini sering muncul saat startup lokal berekspansi dari server lokal ke cloud publik. Penyedia layanan cloud seperti AWS, Google Cloud, dan Azure menawarkan fitur auto-scaling yang canggih, tetapi jika arsitektur aplikasi masih bergantung pada shared state yang tidak efisien, manfaat skala tersebut akan hilang. Perusahaan rintisan di Jakarta, Bandung, dan Surabaya yang menggunakan database bersama untuk sesi pengguna sering mengalami masalah serupa saat trafik meningkat secara tiba-tiba, misalnya pada saat promo besar-besaran atau kampanye pembayaran digital.
"Kami pernah mengalami situasi di mana scaling otomatis kami meningkatkan instance dari dua menjadi sepuluh, namun waktu respons meningkat dua kali lipat," kata Rizky Pratama, CTO sebuah fintech di Jakarta. "Kami baru menyadari bahwa semua instance mengakses tabel Redis yang sama untuk session management. Setiap permintaan harus menulis dan membaca data yang sama, menciptakan bottleneck serial yang tidak dapat diatasi dengan menambahkan instance saja."
Untuk menghindari perangkap ini, tim harus mengidentifikasi titik kontensi sebelum memilih solusi. Gunakan caching, sharding, atau event-driven architecture untuk meminimalkan akses bersamaan ke data kritis. Uji beban harus mensimulasikan skenario di mana semua instance bersaing untuk sumber daya yang sama, bukan hanya menguji throughput pada kondisi idle.
Ke depan, tren serverless dan arsitektur berbasis event bertujuan untuk menghilangkan kebutuhan akan koordinasi antar instance secara eksplisit. Dengan membagi pekerjaan menjadi fungsi yang dipicu oleh peristiwa, sistem dapat menghindari antrian bersama yang menjadi akar masalah scaling. Machine learning juga mulai digunakan untuk memprediksi lonjakan trafik dan menyesuaikan sumber daya secara proaktif, bukan hanya bereaksi terhadap latensi setelah terjadi.
Intinya, scaling yang efektif bukan tentang menyesuaikan pengaturan, melainkan tentang merancang sistem yang benar sejak awal. Jika state yang paling banyak diakses tidak dirancang dengan baik, menambahkan lebih banyak instance hanya akan memperburuk masalah. Desainer sistem harus bertanya pada diri sendiri: bagian mana dari pekerjaan saya yang bersifat serial? Di mana bagian tersebut berada? Jawaban atas pertanyaan ini akan menentukan apakah scaling akan meningkatkan performa atau justru merusaknya.
Bagi perusahaan Indonesia yang ingin memanfaatkan ekonomi skala cloud, pembelajaran ini sangat penting. Mengadopsi teknologi terbaru tanpa memperbaiki desain dasar hanya akan membuang sumber daya. Fokus pada pola desain yang meminimalkan ketergantungan pada state bersama akan memastikan bahwa scaling otomatis benar-benar memberikan manfaat yang dijanjikan oleh penyedia cloud.
Dengan demikian, tim teknis harus memperlakukan scaling sebagai disiplin desain, bukan sebagai tombol yang dapat ditekan. Hanya dengan memahami dan mengatasi fraksi serial dan overhead koordinasi, sistem dapat mencapai performa yang diharapkan, terlepas dari seberapa besar sumber daya yang ditambahkan.
Artikel ini menggarisbawahi bahwa kunci untuk mencapai skalabilitas sejati terletak pada perencanaan arsitektur yang cermat, pengujian yang realistis, dan kesadaran bahwa alat otomatisasi hanyalah pendukung, bukan pengganti bagi desain yang baik.