Harbolnas 2026 akan berlangsung pada 10–16 Desember, dengan target nilai transaksi mencapai Rp40 triliun, naik dari Rp36,4 triliun pada tahun sebelumnya. Cakupannya juga semakin luas, tidak hanya marketplace tetapi juga layanan digital seperti online travel, ride-hailing, dan social commerce.
Bagi bisnis digital, momentum seperti ini biasanya langsung memunculkan pembahasan soal capacity. Apakah infrastructure cukup besar? Apakah application bisa menampung traffic tambahan? Apakah autoscaling sudah aktif?
Pertanyaan tersebut penting, tetapi belum cukup.
Customer tidak berinteraksi dengan infrastructure secara langsung. Mereka mengalami aplikasi: membuka product page, memasukkan barang ke cart, menggunakan promotion, login, melakukan pembayaran, lalu menunggu order confirmation.
Satu bagian dari alur tersebut melambat atau gagal, customer tetap merasakan bahwa aplikasinya bermasalah.
Itulah mengapa peak season seperti Harbolnas lebih tepat dilihat sebagai ujian terhadap application operations secara end-to-end, bukan hanya soal menambah compute menjelang traffic naik.
Application operations adalah bagaimana aplikasi dipantau, dijaga performanya, diskalakan, dan dipulihkan ketika terjadi gangguan selama digunakan.
Untuk workload transaksi, cakupannya tidak berhenti pada server atau container.
Satu checkout dapat bergantung pada authentication, product catalogue, inventory, promotion engine, payment gateway, database, order management, queue, dan third-party API. Customer hanya melihat satu halaman, tetapi di belakangnya terdapat beberapa dependency yang harus bekerja dalam waktu hampir bersamaan.
Karena itu, aplikasi bisa terlihat “up” tetapi tetap memberikan pengalaman yang buruk.
CPU belum penuh, service masih merespons, dan infrastructure monitoring mungkin terlihat normal. Namun payment callback bisa melambat, database connection mulai mencapai limit, atau salah satu external API membutuhkan waktu lebih lama dari biasanya.
AWS Well-Architected juga merekomendasikan monitoring terhadap seluruh komponen workload dan penggunaan end-to-end tracing agar tim dapat melihat bagaimana request bergerak melalui berbagai service dan dependency.
Pada peak season, visibility seperti ini menentukan seberapa cepat tim memahami apa yang sebenarnya terjadi ketika performance mulai turun.
Masalah performance jauh lebih murah ditemukan saat masih ada waktu untuk memperbaikinya.
Jika aplikasi baru diuji pada traffic Harbolnas yang sebenarnya, production traffic pada akhirnya menjadi load test pertama. Pada tahap itu, ruang untuk mengubah architecture, service quota, database configuration, caching strategy, atau scaling policy sudah jauh lebih sempit.
AWS merekomendasikan load testing dengan traffic yang representatif terhadap production serta pengujian pada average usage, peak load, rapid spikes, hingga sustained high load. Pengujian juga sebaiknya tidak berhenti tepat di expected peak; stress test di atas ekspektasi membantu menunjukkan di mana application mulai mengalami degradation atau failure.
Karena Harbolnas memiliki jadwal yang dapat diprediksi, persiapannya juga bisa dilakukan lebih terstruktur.
Tim memiliki waktu untuk menguji transaction flow, mencari bottleneck, memperbaiki alerting, mengevaluasi scaling behaviour, dan memastikan runbook incident sudah relevan sebelum workload masuk ke periode paling sibuk.
Kesalahan yang cukup mudah terjadi adalah melakukan performance test hanya pada satu komponen.
API diuji sendiri. Database diuji sendiri. Infrastructure terlihat mampu menerima load tertentu.
Namun customer tidak menggunakan komponen-komponen tersebut secara terpisah.
Karena itu, load test sebaiknya menggunakan user journey yang representatif. Untuk e-commerce, salah satu yang paling kritis tentu perjalanan dari cart sampai order berhasil tercatat.
Misalnya:
Cart → Promotion → Checkout → Payment → Order Confirmation
Tujuannya bukan sekadar mendapatkan angka requests per second setinggi mungkin.
Yang ingin diketahui adalah bagaimana keseluruhan transaction flow bereaksi ketika concurrent users bertambah. Apakah latency naik secara perlahan atau tiba-tiba? Dependency mana yang mencapai limit lebih dahulu? Apakah error hanya muncul pada payment atau sudah memengaruhi order creation?
AWS secara khusus menyebut testing hanya pada sebagian workload sebagai anti-pattern. Load test sebaiknya menggunakan request mix yang merepresentasikan production dan dilakukan pada environment yang sedekat mungkin dengan kondisi production.
Untuk peak preparation, informasi mengenai breaking point sering kali lebih berguna daripada sekadar memastikan sistem mampu menangani angka traffic yang diperkirakan.
Cloud membuat capacity jauh lebih fleksibel, tetapi tidak semua masalah performance dapat diselesaikan dengan menambah instance.
Application layer mungkin berhasil scale out, sementara database mendekati connection limit.
Worker bertambah, tetapi queue processing masih terlalu lambat.
Front-end tetap responsif, tetapi payment provider mulai mengalami latency.
Atau infrastructure mampu meningkatkan capacity, tetapi scaling baru terjadi setelah customer sudah merasakan slowdown.
AWS Well-Architected merekomendasikan workload dirancang agar dapat beradaptasi terhadap perubahan demand melalui automation dan scaling berdasarkan kebutuhan. Namun testing tetap diperlukan untuk mengetahui bagaimana base resources, scaling configuration, service quotas, dan resiliency design bekerja ketika load benar-benar meningkat.
Jadi pekerjaan sebelum peak bukan hanya memastikan autoscaling tersedia.
Tim juga perlu mengetahui komponen mana yang sebenarnya menjadi batas sistem ketika volume bertambah.
Saat peak traffic, server metrics tetap penting.
CPU utilization, memory, disk, network throughput, database connections, dan queue depth dapat memberikan signal mengenai kondisi workload.
Tetapi application operations juga perlu melihat apa yang dialami customer.
AWS merekomendasikan penggunaan custom metrics yang merepresentasikan customer experience, selain technical metrics dari infrastructure. Distributed tracing kemudian membantu menunjukkan hubungan dan latency di antara berbagai komponen workload.
Untuk commerce application, ini dapat diterjemahkan menjadi signal seperti checkout latency, failed payment, unsuccessful order creation, atau peningkatan error pada transaction path tertentu.
Perbedaannya cukup penting.
Infrastructure monitoring menjawab apakah resource terlihat sehat.
Application-level observability membantu menjawab apakah customer masih bisa menyelesaikan transaksi dengan baik.
Keduanya dibutuhkan agar tim tidak baru mengetahui masalah setelah complaint mulai datang.
Average response time dapat terlihat baik sambil menyembunyikan sebagian customer yang mengalami request jauh lebih lambat.
AWS bahkan menekankan pentingnya memperhatikan latency outlier, bukan hanya average. Ketika traffic bertambah, request lambat yang sebelumnya jarang terjadi mulai mengenai lebih banyak user secara absolut.
Hal ini sangat relevan pada checkout.
Customer mungkin harus menunggu beberapa service selesai sebelum mendapatkan confirmation. Tambahan latency pada authentication, inventory check, payment, atau order processing dapat menumpuk sepanjang request flow.
Karena itu, tracing menjadi berguna untuk menentukan di mana waktu sebenarnya dihabiskan.
Tanpa visibility tersebut, tim berisiko hanya menambah capacity pada service yang bukan sumber bottleneck.
Peak readiness sebaiknya dimulai dari critical transaction path dan operating condition yang memang akan dihadapi aplikasi.
Pertama, tentukan performance requirement yang jelas. Berapa response time yang masih acceptable? Berapa throughput yang perlu ditangani? Di titik mana degradation sudah dianggap incident?
Kemudian uji aplikasi menggunakan traffic pattern yang realistis. Jangan hanya menguji kenaikan traffic secara bertahap; masukkan juga sudden spike dan sustained high load karena behaviour keduanya bisa menghasilkan bottleneck yang berbeda.
Hasil pengujian tersebut kemudian menjadi dasar untuk mengevaluasi scaling policy, service quota, database behaviour, external dependency, dan monitoring threshold.
Di tahap ini, tim juga perlu memastikan apa yang terjadi ketika satu dependency gagal.
Tidak semua masalah harus berakhir pada total outage. Dalam beberapa kondisi, application dapat menggunakan retry, queue, circuit breaker, degraded mode, atau fallback tertentu agar sebagian fungsi tetap berjalan.
Keputusan seperti ini sebaiknya sudah ditentukan sebelum peak, bukan dirancang saat incident sedang berlangsung.
Load testing dapat membantu mencegah banyak problem, tetapi tidak mungkin menghilangkan seluruh risiko.
Karena itu, operational readiness juga berarti mengetahui apa yang harus dilakukan ketika aplikasi mulai mengalami degradation.
Alert perlu cukup actionable agar on-call engineer memahami apa yang perlu diperiksa. Dashboard perlu menunjukkan context, bukan hanya puluhan metric tanpa prioritas. Tim juga perlu tahu siapa yang bertanggung jawab terhadap application, database, network, atau third-party integration ketika incident melibatkan beberapa domain sekaligus.
Jika suatu service perlu di-scale secara manual, prosedurnya harus sudah diketahui.
Jika deployment terakhir perlu di-rollback, jalurnya harus cukup cepat.
Jika payment provider bermasalah, perusahaan perlu mengetahui apa yang terjadi terhadap transaction yang sudah masuk tetapi belum mendapat confirmation.
Di sinilah Apps Operations berbeda dengan sekadar infrastructure monitoring.
Tujuannya bukan hanya mengetahui bahwa ada masalah, tetapi memperpendek waktu dari detection → diagnosis → recovery.
Data Bank Indonesia terbaru tidak menunjukkan retail sedang mengalami perlambatan secara tahunan.
Realisasi Indeks Penjualan Riil pada Agustus 2026 tumbuh 1,3% YoY, meningkat dari 1,1% pada Juli. Untuk September, BI memperkirakan pertumbuhan kembali naik menjadi 1,4% YoY.
Data tersebut tidak dapat digunakan untuk memprediksi traffic sebuah aplikasi tertentu. Namun bersama target Harbolnas Rp40 triliun, angka tersebut memberikan konteks bahwa bisnis digital memasuki periode akhir tahun dengan aktivitas konsumsi yang masih bergerak positif.
Karena itu, workload preparation tetap perlu didasarkan pada historical traffic dan forecast masing-masing bisnis, bukan pada angka nasional saja.
Peak readiness selalu bersifat workload-specific.
Tidak ada satu indikator yang bisa menjawab semuanya.
Application lebih siap ketika tim sudah memahami performance limit-nya, bukan hanya berharap autoscaling akan bekerja ketika traffic naik.
Critical transaction flow sudah diuji pada realistic peak load. Scaling behaviour sudah diamati. Bottleneck dan quota sudah diketahui. Customer-facing metrics tersedia. Alert sudah mengarah pada signal yang benar. Trace dapat digunakan untuk mengikuti request end-to-end.
Dan ketika sesuatu tetap gagal, tim sudah memiliki prosedur untuk meresponsnya.
AWS menyebut scaling and performance testing sebagai proses berkelanjutan, bukan aktivitas sekali jalan. Data dari production kemudian digunakan kembali untuk memperbaiki test scenario dan optimization berikutnya.
Dengan kata lain, peak readiness bukan kondisi yang dicapai melalui satu load test seminggu sebelum event.
Ia dibangun melalui cara aplikasi dioperasikan sepanjang waktu.
Harbolnas berlangsung selama tujuh hari. Namun kesiapan application untuk periode tersebut dibangun jauh sebelumnya.
Traffic yang lebih tinggi akan membuat limit yang selama kondisi normal jarang terlihat menjadi lebih mudah muncul. Database, queue, API dependency, third-party services, dan scaling configuration semuanya ikut diuji ketika lebih banyak customer mencoba bertransaksi dalam waktu yang sama.
Karena itu, pertanyaan menjelang peak season seharusnya tidak berhenti pada:
“Apakah server kita cukup?”
Yang perlu diketahui adalah bagaimana application berperilaku ketika workload berada di bawah tekanan, apakah tim dapat melihat degradation cukup dini, dan apakah response yang dibutuhkan sudah siap ketika incident terjadi.
Harbolnas dimulai pada Desember. Application operations readiness perlu dibangun jauh sebelum traffic datang.
ICS Compute membantu bisnis mengoperasikan cloud application dengan fokus pada performance, reliability, scalability, observability, dan incident readiness untuk workload yang perlu tetap tersedia ketika demand meningkat.