Scalability Testing: Bisnis Sukses, Sistem Justru Runtuh

Banyak sistem gagal bukan karena produknya buruk, tidak digunakan, atau tidak memiliki pasar. Sebaliknya, sistem dapat gagal justru ketika bisnis mulai berhasil.

Kampanye marketing mendatangkan pengguna dalam jumlah besar. Produk menjadi viral. Perusahaan mendapatkan klien enterprise baru. Transaksi tumbuh lebih cepat daripada proyeksi. Jumlah cabang meningkat, data bertambah, dan semakin banyak tim bergantung pada aplikasi yang sama.

Sistem yang sebelumnya terlihat stabil kemudian mulai melambat.

Halaman membutuhkan waktu lebih lama untuk dibuka. Proses checkout gagal. Data terlambat diperbarui. Pengguna mencoba menekan tombol berkali-kali. Queue menumpuk, koneksi database habis, dan layanan lain ikut mengalami gangguan.

Dalam kondisi tersebut, masalahnya bukan karena sistem tidak pernah “jalan baik”.

Masalahnya adalah sistem hanya pernah terbukti berjalan baik pada kapasitas yang jauh lebih kecil.

Di sinilah scalability testing menjadi penting.

Scalability testing adalah proses menguji bagaimana performa, stabilitas, dan penggunaan sumber daya sistem berubah ketika jumlah pengguna, transaksi, data, atau pekerjaan meningkat.

Tujuannya bukan hanya memastikan aplikasi dapat menerima banyak request. Perusahaan perlu memahami:

• Kapasitas maksimum sistem saat ini.
• Komponen yang menjadi bottleneck pertama.
• Bagaimana performa menurun ketika beban meningkat.
• Apakah sistem dapat menambah kapasitas secara otomatis.
• Berapa lama sistem dapat bertahan pada beban tinggi.
• Bagaimana sistem pulih setelah mengalami overload.
• Berapa biaya infrastruktur pada setiap tingkat penggunaan.
• Apakah fungsi bisnis kritis tetap tersedia saat kapasitas terbatas.

Scalability testing mengubah asumsi seperti “seharusnya server bisa menangani” menjadi bukti yang dapat diukur.

Sistem yang Berfungsi Belum Tentu Siap Bertumbuh

Functional testing menjawab pertanyaan:

Apakah fitur bekerja sesuai dengan requirement?

Scalability testing menjawab pertanyaan yang berbeda:

Apakah fitur tersebut tetap bekerja ketika digunakan secara bersamaan oleh pengguna dalam jumlah besar?

Sebuah fungsi checkout dapat bekerja sempurna ketika diuji oleh satu QA engineer. Namun, hasilnya dapat berubah ketika ribuan pengguna melakukan checkout pada waktu bersamaan.

Query database yang membutuhkan 100 milidetik pada data development dapat membutuhkan beberapa detik ketika tabel berisi puluhan juta baris.

Proses pembuatan laporan dapat berjalan lancar untuk satu cabang, tetapi menghabiskan kapasitas database ketika seluruh cabang membuat laporan pada akhir bulan.

Artinya, sistem yang benar secara fungsional belum tentu cukup kuat secara operasional.

Kualitas software tidak hanya ditentukan oleh kemampuan menghasilkan output yang benar. Sistem juga harus menghasilkan output tersebut dalam waktu yang dapat diterima, pada volume penggunaan yang sesuai, tanpa menciptakan gangguan pada komponen lain.

Mengapa Kesuksesan Dapat Menjadi Sumber Kegagalan?

Pertumbuhan bisnis meningkatkan beban sistem melalui berbagai cara.

Jumlah Pengguna Bertambah

Startup dapat mengalami pertumbuhan pengguna setelah peluncuran produk, kampanye digital, pemberitaan media, kolaborasi, atau program referral.

Pada perusahaan enterprise, pertumbuhan dapat berasal dari penambahan cabang, distributor, mitra, karyawan, atau integrasi pelanggan.

Masalahnya, pengguna tidak selalu datang secara merata sepanjang hari.

Beban dapat terkonsentrasi pada:

• Jam masuk kerja.
• Waktu pembayaran gaji.
• Penutupan periode keuangan.
• Pembukaan penjualan tiket.
• Flash sale.
• Peluncuran produk.
• Batas waktu pelaporan.
• Pengumuman hasil seleksi.
• Kampanye promosi.
• Perubahan harga.

Jumlah pengguna bulanan tidak cukup untuk menggambarkan tekanan terhadap sistem. Perusahaan perlu mengetahui berapa banyak pengguna yang aktif secara bersamaan dan aktivitas apa yang mereka lakukan.

Volume Transaksi Meningkat Lebih Cepat daripada Pengguna

Satu pengguna tidak selalu menghasilkan satu request.

Ketika membuka satu dashboard, aplikasi dapat memanggil banyak API, menjalankan beberapa query, mengambil notifikasi, memuat grafik, dan menghubungi layanan pihak ketiga.

Fitur baru juga dapat meningkatkan jumlah pekerjaan per pengguna.

Sebuah aplikasi yang awalnya hanya menampilkan katalog kemudian menambahkan rekomendasi, loyalty point, real-time inventory, payment verification, dan notifikasi. Jumlah pengguna mungkin hanya bertambah dua kali, tetapi pekerjaan yang harus dilakukan sistem dapat meningkat jauh lebih besar.

Data Terus Terakumulasi

Sistem yang cepat pada tahun pertama dapat melambat setelah digunakan selama beberapa tahun.

Setiap transaksi, log, file, histori perubahan, aktivitas pengguna, dan audit trail menambah volume data.

Pertumbuhan data dapat memengaruhi:

• Kecepatan query.
• Waktu backup.
• Waktu pemulihan.
• Ukuran indeks.
• Durasi pembuatan laporan.
• Kebutuhan penyimpanan.
• Biaya infrastruktur.
• Waktu migrasi.
• Proses sinkronisasi.

Scalability testing tidak hanya menguji lebih banyak pengguna. Pengujian juga perlu menggunakan volume data yang mendekati kondisi masa depan.

Integrasi Memperluas Titik Kegagalan

Sistem startup dan enterprise semakin bergantung pada payment gateway, ERP, CRM, layanan pengiriman, identity provider, cloud storage, platform komunikasi, serta API pihak ketiga.

Ketika beban naik, masalah dapat muncul pada batas integrasi.

Sistem internal mungkin mampu memproses 1.000 transaksi per detik, sedangkan API pihak ketiga hanya menerima 100 transaksi per detik. Request mulai menumpuk, timeout meningkat, lalu retry otomatis justru menambah beban.

Tanpa pengendalian yang tepat, kegagalan satu integrasi dapat menyebar menjadi gangguan sistemik.

Pola Penggunaan Berubah

Proyeksi awal sering mengasumsikan aktivitas pengguna tersebar secara normal.

Kenyataannya, kesuksesan dapat menciptakan pola yang sangat berbeda.

Pengguna dapat berulang kali menekan refresh karena halaman lambat. Aplikasi mobile dapat mengirim request berulang setelah koneksi kembali tersedia. Bot, webhook, scheduled job, dan proses background dapat berjalan bersamaan dengan trafik pengguna.

Karena itu, scalability testing perlu meniru perilaku sistem secara menyeluruh, bukan hanya menambah jumlah request ke satu halaman.

Pelajaran dari Peluncuran Pokémon GO

Peluncuran Pokémon GO memberikan gambaran mengenai sulitnya memprediksi skala kesuksesan.

Dalam studi kasus resmi Google Cloud mengenai peluncuran Pokémon GO, tim menargetkan kapasitas awal pada tingkat 1X dan membuat estimasi terburuk sekitar 5X.

Popularitas aplikasi tersebut kemudian mendorong trafik pengguna hingga sekitar 50X dari target awal. Angka tersebut sepuluh kali lebih besar daripada estimasi terburuk yang sudah disiapkan.

Kasus ini tidak berarti setiap startup harus menyediakan kapasitas 50 kali proyeksinya.

Pelajaran yang lebih penting adalah bahwa permintaan aktual dapat bergerak jauh di luar asumsi ketika produk berhasil. Tim tidak dapat hanya mengandalkan estimasi di atas spreadsheet.

Google SRE melalui pembahasan mengenai reliable product launches juga menjelaskan bahwa sangat sulit memprediksi respons layanan terhadap overload hanya berdasarkan teori. Karena itu, load test digunakan untuk reliability dan capacity planning sebelum peluncuran.

Bagi startup dan scale-up, pertanyaannya bukan apakah produk akan mengalami pertumbuhan sebesar Pokémon GO.

Pertanyaannya adalah:

Apa yang terjadi jika pertumbuhan aktual tiga, lima, atau sepuluh kali lebih tinggi daripada skenario yang pernah diuji?

Apa Perbedaan Scalability Testing dan Performance Testing?

Istilah performance testing, load testing, stress testing, dan scalability testing sering digunakan secara bergantian. Padahal, fokusnya berbeda.

Performance testing merupakan kategori besar untuk mengevaluasi kecepatan, stabilitas, penggunaan resource, dan respons sistem pada berbagai kondisi.

Load testing menguji apakah sistem mampu menangani beban yang diharapkan.

Stress testing meningkatkan beban melampaui kondisi normal untuk melihat batas dan perilaku sistem ketika mulai mengalami tekanan.

Scalability testing menilai bagaimana kemampuan sistem berubah ketika demand dan resource ditambah.

Scalability testing tidak hanya bertanya, “Berapa banyak pengguna yang dapat ditangani?”

Pengujian juga perlu menjawab:

• Apakah menambah server benar-benar meningkatkan kapasitas?
• Apakah peningkatan kapasitas bersifat linear?
• Komponen apa yang tidak ikut bertambah kapasitasnya?
• Apakah autoscaling aktif cukup cepat?
• Apakah biaya meningkat secara proporsional?
• Apakah sistem tetap stabil setelah scale-out dan scale-in?
• Apakah data tetap konsisten saat banyak proses berjalan bersamaan?

Microsoft melalui panduan performance testing menempatkan speed, stability, dan scalability sebagai aspek berbeda yang perlu dievaluasi melalui beberapa jenis pengujian.

Jenis Pengujian yang Dibutuhkan

Satu load test tidak cukup untuk menggambarkan seluruh risiko skalabilitas.

Smoke Test

Smoke test menjalankan beban sangat kecil untuk memastikan script, environment, dan sistem pengujian bekerja dengan benar.

Tahap ini mencegah tim menjalankan pengujian besar menggunakan konfigurasi yang salah.

Average-load Test

Pengujian ini mensimulasikan beban normal sehari-hari.

Tujuannya adalah memastikan response time, error rate, throughput, serta penggunaan resource tetap berada dalam batas yang diterima pada kondisi operasional biasa.

Load Test

Load test menggunakan jumlah pengguna atau transaksi sesuai kapasitas yang diperkirakan.

Misalnya, perusahaan memperkirakan 2.000 pengguna aktif bersamaan pada jam sibuk. Pengujian perlu mensimulasikan skenario tersebut dengan pola aktivitas yang realistis.

Stress Test

Stress test mendorong sistem melampaui kapasitas normal.

Tujuannya bukan memaksa sistem rusak tanpa alasan. Tim perlu mengetahui kapan performa mulai menurun, bottleneck apa yang muncul, dan apakah sistem mengalami kegagalan secara terkendali.

Spike Test

Spike test menguji lonjakan trafik yang terjadi sangat cepat.

Grafana k6 menjelaskan bahwa spike testing relevan untuk kondisi seperti peluncuran produk, penjualan tiket, kampanye besar, batas waktu pajak, dan flash sale.

Sistem yang mampu menangani peningkatan bertahap belum tentu mampu menangani lonjakan mendadak. Autoscaling membutuhkan waktu, koneksi baru perlu dibuat, dan cache mungkin belum siap.

Soak Test

Soak test menjalankan beban dalam durasi panjang.

Pengujian ini mencari masalah yang tidak terlihat dalam tes singkat, seperti:

• Memory leak.
• Koneksi yang tidak dilepas.
• Queue yang terus bertambah.
• Disk yang perlahan penuh.
• Cache yang membesar.
• Token yang kedaluwarsa.
• Penurunan performa bertahap.
• Scheduled job yang bertabrakan.

Sistem dapat bertahan selama 15 menit pada beban tinggi, tetapi mulai bermasalah setelah berjalan delapan jam.

Breakpoint Test

Breakpoint test meningkatkan beban secara bertahap sampai sistem mencapai batasnya.

Tujuannya adalah menemukan kapasitas maksimum saat ini dan memahami pola kerusakannya.

Tim perlu mengetahui apakah sistem:

• Menolak sebagian request secara terkendali.
• Menjadi lambat secara bertahap.
• Langsung mengalami crash.
• Membuat seluruh dependency ikut gagal.
• Pulih setelah beban diturunkan.
• Membutuhkan restart manual.

Failover dan Recovery Test

Scalability bukan hanya kemampuan menerima beban ketika seluruh komponen sehat.

Perusahaan juga perlu menguji kondisi ketika satu server, database replica, availability zone, network, atau layanan pendukung tidak tersedia.

Pertanyaan utamanya adalah apakah kapasitas yang tersisa masih cukup untuk menjaga fungsi kritis.

Matriks Sederhana Scalability Testing

Persentase dan durasi pengujian harus disesuaikan dengan risiko serta konteks sistem. Tidak terdapat satu angka universal untuk semua aplikasi.

Metrik yang Harus Dipantau

Scalability testing tidak cukup hanya melihat apakah server mengalami crash.

Response Time

Response time mengukur waktu yang dibutuhkan sistem untuk menyelesaikan request.

Jangan hanya menggunakan nilai rata-rata.

Rata-rata dapat terlihat baik meskipun sebagian pengguna mengalami respons yang sangat lambat. Karena itu, tim perlu memantau percentile seperti p50, p95, dan p99.

P95 menunjukkan bahwa 95 persen request selesai di bawah waktu tersebut, sedangkan lima persen sisanya lebih lambat.

Untuk sistem transaksi, kelompok pengguna yang berada pada lima persen tersebut tetap dapat mewakili ribuan transaksi.

Throughput

Throughput menunjukkan jumlah pekerjaan yang dapat diselesaikan sistem dalam satu periode, misalnya:

• Request per second.
• Transaksi per menit.
• Pesanan per jam.
• Dokumen per detik.
• Pesan yang diproses per menit.

Throughput membantu melihat apakah penambahan beban benar-benar menghasilkan lebih banyak pekerjaan selesai atau hanya menambah antrean.

Error Rate

Error rate menunjukkan persentase request yang gagal.

Tim perlu membedakan jenis kegagalan:

• Timeout.
• Server error.
• Rate limit.
• Database error.
• Authentication failure.
• Business validation.
• Dependency failure.

Peningkatan error rate sering menjadi sinyal bahwa sistem mendekati batas sebelum terjadi kegagalan total.

Concurrent Users dan Concurrent Requests

Jumlah pengguna aktif tidak selalu sama dengan jumlah request bersamaan.

Seorang pengguna dapat menunggu, membaca halaman, atau menjalankan beberapa request secara paralel.

Model pengujian perlu mempertimbangkan pola aktivitas aktual, durasi session, think time, dan jumlah request yang dibuat setiap aktivitas.

CPU, Memory, Disk, dan Network

Metrik infrastruktur membantu mengetahui resource yang menjadi batas.

Namun, penggunaan CPU rendah tidak selalu berarti sistem masih memiliki kapasitas besar.

Bottleneck dapat berada pada:

• Database lock.
• Connection pool.
• External API.
• Disk input/output.
• Queue.
• Thread pool.
• Cache.
• Network.
• Application-level concurrency.

Database Metrics

Database sering menjadi bottleneck pertama pada sistem yang bertumbuh.

Pantau:

• Query latency.
• Active connection.
• Lock dan deadlock.
• Cache hit ratio.
• Read dan write throughput.
• Replication lag.
• Index usage.
• Storage growth.
• Slow query.

Menambah application server tidak membantu jika seluruh server tetap bergantung pada database yang sama dan sudah mencapai batas.

Queue Depth dan Processing Lag

Untuk sistem asynchronous, jumlah request yang diterima tidak sama dengan jumlah pekerjaan yang selesai.

Queue dapat menyerap lonjakan sementara, tetapi backlog yang terus bertambah menunjukkan bahwa downstream processor tidak mampu mengejar demand.

Cost per Transaction

Sistem dapat secara teknis scalable tetapi tidak ekonomis.

Jika setiap peningkatan transaksi membutuhkan biaya infrastruktur yang tumbuh lebih cepat daripada pendapatan, model skalabilitasnya bermasalah.

Karena itu, perusahaan perlu mengukur biaya per pengguna, transaksi, dokumen, atau workload.

Autoscaling Bukan Jaminan Sistem Akan Aman

Cloud platform memudahkan perusahaan menambah instance secara otomatis.

Namun, autoscaling tidak menyelesaikan semua masalah skalabilitas.

Autoscaling hanya bekerja jika:

• Metrik pemicunya tepat.
• Resource baru dapat aktif cukup cepat.
• Aplikasi dapat dijalankan pada banyak instance.
• Session tidak terkunci pada satu server.
• Database masih memiliki kapasitas.
• Dependency dapat menerima tambahan trafik.
• Queue dan storage dapat ikut berkembang.
• Batas akun atau quota belum tercapai.

AWS menyarankan penggunaan load testing untuk menentukan scaling metric dan memahami hubungan antara throughput, concurrency, pengguna, dan resource yang dibutuhkan melalui panduan proactive autoscaling.

Sistem juga dapat mengalami masalah ketika autoscaling terlambat.

Lonjakan trafik terjadi dalam hitungan detik, sedangkan instance baru mungkin membutuhkan beberapa menit untuk siap. Selama jeda tersebut, request menumpuk dan pengguna mengulang aktivitasnya.

Karena itu, sistem dengan pola spike perlu mempertimbangkan kapasitas awal, pre-scaling, queue, caching, rate limiting, dan load shedding.

Skalabilitas Bukan Hanya Masalah Server

Kesalahan umum lainnya adalah menganggap semua masalah dapat diselesaikan dengan menambah server.

Sistem terdiri dari rantai komponen. Kapasitasnya ditentukan oleh bagian dengan batas paling rendah.

Bottleneck dapat berada pada:

• Desain database.
• Query yang tidak efisien.
• Satu proses synchronous.
• File storage.
• Session management.
• API pihak ketiga.
• Payment gateway.
• Sistem autentikasi.
• Message broker.
• Proses pembuatan laporan.
• Lock pada data tertentu.
• Kode yang menggunakan banyak memory.
• Arsitektur yang terlalu terikat.

Ketika bottleneck pertama diperbaiki, bottleneck berikutnya dapat muncul.

Inilah sebabnya scalability testing perlu dilakukan secara iteratif. Pengujian bukan aktivitas sekali sebelum go-live, tetapi proses untuk memahami perubahan kapasitas setelah arsitektur, fitur, dan pola penggunaan berkembang.

Masalah skalabilitas juga dapat diperburuk oleh technical debt. Query sementara, dependency yang terlalu rapat, kode berulang, dan kurangnya observability membuat bottleneck lebih sulit ditemukan dan diperbaiki.

Cara Membuat Skenario Pengujian yang Realistis

Mulai dari Perilaku Bisnis, Bukan Jumlah Request

Jangan hanya menentukan bahwa sistem harus menerima 10.000 request per detik.

Petakan aktivitas pengguna:

• Login.
• Mencari produk.
• Membuka detail.
• Menambahkan ke keranjang.
• Melakukan checkout.
• Memproses pembayaran.
• Memeriksa status.
• Mengunduh laporan.
• Mengunggah dokumen.

Setiap aktivitas menghasilkan pola request dan beban yang berbeda.

Gunakan Data Historis

Analytics, application log, database log, dan monitoring dapat digunakan untuk memahami:

• Jam sibuk.
• Concurrent users.
• Endpoint yang paling sering digunakan.
• Ukuran request.
• Durasi session.
• Rasio read dan write.
• Pertumbuhan transaksi.
• Pola error.
• Ketergantungan pada layanan lain.

Untuk produk baru, gunakan asumsi yang dinyatakan secara terbuka dan buat beberapa skenario.

Buat Beberapa Proyeksi

Gunakan setidaknya:

• Skenario normal.
• Skenario pertumbuhan.
• Skenario puncak.
• Skenario ekstrem yang masih masuk akal.

Contohnya, startup dapat menguji 1X, 3X, 5X, dan 10X dari estimasi awal.

Tujuannya bukan menjamin sistem selalu aman pada seluruh skenario, tetapi mengetahui batas dan rencana respons untuk masing-masing kondisi.

Gunakan Volume Data yang Representatif

Pengujian pada database kosong sering menghasilkan rasa aman yang keliru.

Gunakan ukuran data yang mendekati proyeksi enam bulan, satu tahun, atau beberapa tahun mendatang.

Data juga perlu memiliki distribusi realistis. Satu pelanggan besar dapat memiliki aktivitas jauh lebih tinggi dibandingkan pelanggan lainnya.

Uji Seluruh Alur Kritis

Jangan hanya menguji homepage atau endpoint yang paling mudah.

Fokus pada proses yang memengaruhi pendapatan dan operasional, seperti:

• Checkout.
• Payment.
• Order processing.
• Stock reservation.
• Approval.
• Data synchronization.
• Reporting.
• User authentication.
• File processing.

Libatkan Dependency

Jika pengujian menggunakan mock untuk seluruh layanan eksternal, hasilnya tidak menggambarkan batas integrasi sebenarnya.

Namun, mengirim trafik besar ke layanan pihak ketiga tanpa persetujuan juga berisiko dan dapat menimbulkan biaya.

Tim perlu menentukan dependency mana yang diuji secara nyata, disimulasikan, atau diuji melalui sandbox dengan batas yang terdokumentasi.

Tentukan Kriteria Lulus Sebelum Pengujian

Tanpa kriteria yang jelas, tim dapat melihat hasil yang sama dan mengambil kesimpulan berbeda.

Contoh kriteria:

• P95 response time di bawah dua detik.
• Error rate di bawah satu persen.
• Checkout success rate di atas 99 persen.
• Queue kembali normal dalam sepuluh menit.
• Tidak terjadi kehilangan atau duplikasi transaksi.
• Autoscaling aktif sebelum CPU mencapai batas kritis.
• Sistem pulih tanpa restart manual.
• Biaya per transaksi berada di bawah target.
• Fungsi prioritas tetap tersedia saat overload.
• Tidak ada replication lag di atas batas yang ditentukan.

Angka tersebut harus ditentukan berdasarkan kebutuhan bisnis, bukan disalin dari aplikasi lain.

Sistem informasi internal mungkin dapat menerima waktu respons beberapa detik. Sistem pembayaran atau bidding real-time memiliki kebutuhan berbeda.

Uji Cara Sistem Mengalami Kegagalan

Tujuan scalability testing bukan memastikan sistem tidak pernah gagal.

Setiap sistem memiliki batas.

Tujuan yang lebih realistis adalah memastikan kegagalan terjadi secara terkendali.

Ketika kapasitas tidak mencukupi, sistem dapat:

• Menolak request berprioritas rendah.
• Menampilkan antrean.
• Membatasi rate.
• Menghentikan fitur nonkritis.
• Menggunakan data cache.
• Memproses aktivitas secara asynchronous.
• Menjaga transaksi utama tetap tersedia.
• Memberikan pesan yang jelas kepada pengguna.

Netflix menggunakan pendekatan prioritized load shedding untuk mengurangi trafik berprioritas rendah ketika resource berada di bawah tekanan, sehingga kapasitas dapat dipertahankan untuk request yang lebih penting.

Konsep tersebut relevan untuk berbagai sistem. Ketika kapasitas terbatas, perusahaan perlu mengetahui fungsi apa yang harus tetap hidup.

Kapan Scalability Testing Harus Dilakukan?

Scalability testing tidak harus menunggu aplikasi selesai sepenuhnya.

Pengujian dapat dilakukan:

Sebelum Peluncuran

Uji core workflow dan kapasitas target sebelum produk tersedia untuk pengguna.

Sebelum Kampanye Besar

Lakukan spike test dan capacity review sebelum promosi, peluncuran, atau event yang dapat meningkatkan trafik.

Sebelum Onboarding Klien Besar

Satu klien enterprise dapat menambah pengguna, transaksi, file, integrasi, dan kebutuhan reporting secara signifikan.

Setelah Perubahan Arsitektur

Perubahan database, cache, queue, API gateway, atau deployment dapat mengubah karakteristik kapasitas sistem.

Setelah Menambahkan Fitur Berat

AI inference, laporan kompleks, pemrosesan dokumen, media, atau real-time analytics dapat menambah beban yang berbeda.

Secara Berkala

Pertumbuhan data dan perubahan dependency dapat membuat hasil pengujian lama tidak lagi relevan.

Shopify menjelaskan bahwa load dan stress testing dilakukan secara proaktif untuk memahami perilaku platform sebelum flash sale dan periode trafik besar. Pengujian tersebut mensimulasikan browsing, penambahan keranjang, checkout, dan lonjakan aktivitas yang menyerupai kondisi nyata melalui program performance testing berskala besar.

Scalability Testing untuk Startup dan Scale-up

Startup sering menunda scalability testing karena ingin memvalidasi pasar terlebih dahulu.

Keputusan ini dapat masuk akal. Tidak efisien membangun arsitektur untuk jutaan pengguna sebelum produk memiliki permintaan.

Namun, terdapat perbedaan antara tidak melakukan over-engineering dan tidak mengetahui batas sistem.

Startup tidak harus memiliki infrastruktur berskala global pada hari pertama. Namun, tim setidaknya perlu mengetahui:

• Batas kapasitas saat ini.
• Bottleneck paling mungkin.
• Waktu yang dibutuhkan untuk menambah resource.
• Skenario pertumbuhan terdekat.
• Komponen yang sulit ditingkatkan.
• Cara melindungi fungsi utama ketika overload.
• Risiko kehilangan data.
• Cara melakukan recovery.

Prinsipnya adalah scale-aware, bukan selalu built for infinite scale.

Pada fase scale-up, pengujian perlu menjadi lebih terstruktur karena sistem telah menjadi bagian penting dari bisnis.

Kegagalan tidak hanya mengganggu eksperimen produk. Gangguan dapat memengaruhi pendapatan, SLA, kepercayaan pelanggan, dan reputasi perusahaan.

Kesalahan dalam Scalability Testing

Menguji Endpoint yang Mudah Saja

Hasil terlihat baik karena alur transaksi, database write, dan integrasi tidak benar-benar diuji.

Menggunakan Data Terlalu Sedikit

Database development tidak mewakili kondisi setelah beberapa tahun penggunaan.

Hanya Melihat Average Response Time

Sebagian pengguna dapat mengalami latency sangat tinggi meskipun rata-rata terlihat normal.

Mengabaikan Waktu Pemanasan

Cache dingin, koneksi baru, dan instance baru dapat menghasilkan perilaku berbeda pada awal lonjakan.

Menganggap Cloud Pasti Scalable

Cloud menyediakan resource, tetapi arsitektur aplikasi tetap dapat memiliki bottleneck.

Tidak Memantau Dependency

Tim hanya memeriksa CPU aplikasi dan melewatkan database, queue, storage, serta layanan eksternal.

Menguji tanpa Kriteria Lulus

Tim menghasilkan banyak grafik, tetapi tidak dapat menyimpulkan apakah sistem siap.

Mengoptimalkan Terlalu Dini

Perusahaan mengubah arsitektur menjadi sangat kompleks sebelum mengetahui bottleneck aktual.

Tidak Menguji Recovery

Sistem berhasil bertahan pada beban, tetapi tidak dapat pulih secara otomatis setelah mengalami gangguan.

Menjalankan Pengujian Besar tanpa Kontrol

Load test dapat menyebabkan gangguan, menghasilkan biaya cloud tinggi, mengirim notifikasi nyata, atau memproses transaksi pihak ketiga.

Pengujian harus memiliki environment, izin, batas, monitoring, serta prosedur penghentian yang jelas.

Hubungan Scalability Testing dengan Cost of Change

Masalah kapasitas yang ditemukan saat pengujian masih dapat ditangani secara terencana.

Tim dapat memperbaiki query, menambah cache, mengubah konfigurasi, menyesuaikan queue, atau meningkatkan resource sebelum pengguna terdampak.

Masalah yang sama menjadi lebih mahal ketika ditemukan setelah kampanye berjalan atau ribuan pengguna gagal bertransaksi.

Biayanya dapat mencakup:

• Kehilangan penjualan.
• Refund.
• Pelanggaran SLA.
• Penambahan infrastruktur darurat.
• Hotfix.
• Overtime.
• Pemulihan data.
• Customer support.
• Kerusakan reputasi.

Hubungan ini sejalan dengan konsep Cost of Change: masalah yang ditemukan setelah sistem menjadi bagian penting dari operasional dapat menghasilkan dampak yang jauh lebih luas daripada biaya teknis perbaikannya.

Scalability testing memindahkan penemuan masalah ke waktu ketika tim masih memiliki ruang untuk mengambil keputusan.

Dari Hasil Pengujian ke Keputusan Bisnis

Hasil scalability testing seharusnya tidak berhenti sebagai laporan teknis.

Manajemen membutuhkan jawaban seperti:

• Berapa kapasitas bisnis yang dapat ditangani sistem?
• Kapan investasi infrastruktur perlu ditambah?
• Apakah kampanye dapat dijalankan dengan aman?
• Berapa banyak klien baru yang dapat di-onboard?
• Bagian mana yang harus dimodernisasi?
• Berapa biaya untuk mencapai skala berikutnya?
• Apa risiko jika pertumbuhan lebih tinggi dari perkiraan?
• Berapa lama sistem dapat dipulihkan?

Hasil pengujian dapat diterjemahkan menjadi capacity roadmap.

Contohnya:

Angka pada tabel harus berasal dari hasil pengujian aktual, bukan asumsi.

Kesimpulan

Sistem tidak selalu runtuh karena dibuat dengan buruk.

Sistem dapat runtuh karena digunakan pada tingkat keberhasilan yang belum pernah dipersiapkan dan diuji.

Functional testing membuktikan bahwa fitur bekerja. Scalability testing membuktikan apakah fitur tersebut tetap dapat digunakan ketika jumlah pengguna, transaksi, data, dan dependency meningkat.

Pengujian yang baik perlu mencakup average load, peak load, spike, stress, soak, breakpoint, failover, dan recovery sesuai risiko sistem.

Perusahaan juga perlu memantau response time percentile, throughput, error rate, database, queue, resource, biaya, dan konsistensi data.

Tujuannya bukan membangun sistem dengan kapasitas tanpa batas.

Tujuannya adalah mengetahui batas saat ini, memahami cara sistem mengalami tekanan, dan memiliki rencana untuk mencapai skala berikutnya sebelum pertumbuhan datang.

Bagi startup dan scale-up, scalability testing bukan pengeluaran untuk masalah yang belum terjadi.

Scalability testing adalah cara memastikan kesuksesan produk tidak berubah menjadi penyebab kegagalan operasional.

Persiapkan Sistem untuk Pertumbuhan Bersama Crocodic

Crocodic membantu perusahaan merancang, mengembangkan, dan meningkatkan sistem enterprise agar mampu mengikuti pertumbuhan pengguna, transaksi, data, serta integrasi bisnis.

Melalui layanan Custom Enterprise Software, Crocodic membantu membangun sistem berdasarkan kebutuhan operasional dan proyeksi pertumbuhan yang relevan, bukan hanya memastikan fitur bekerja pada kondisi development.

Untuk perusahaan yang sudah memiliki aplikasi tetapi mulai menghadapi performa lambat, keterbatasan multi-user, bottleneck database, atau kesulitan menambah kapasitas, Crocodic menyediakan layanan Enterprise System Upgrade.

Peningkatan dapat dilakukan melalui assessment arsitektur, optimasi performa, API integration, perbaikan database, observability, automation, serta pengembangan kapasitas secara bertahap tanpa selalu membangun ulang seluruh sistem.

Jika bisnis Anda sedang bertumbuh, akan menjalankan kampanye besar, menambah pengguna enterprise, atau mulai khawatir sistem tidak mampu mengikuti demand, jangan menunggu kegagalan production untuk menemukan batasnya.

Diskusikan kesiapan skalabilitas dan kebutuhan peningkatan sistem perusahaan Anda bersama Crocodic.