Bayangkan sistem yang sepanjang minggu nyaris tidak melayani siapa pun, lalu pada satu menit tertentu harus melayani puluhan ribu orang sekaligus. Itu profil beban kerja penjualan tiket pertandingan sepak bola, dan itu pula alasan cloud untuk lonjakan trafik jadi topik yang serius di industri ini.

Ada satu hal yang membuat tantangan ini beda dari sistem lain: tidak ada kesempatan kedua. Kalau sistem tersendat pada menit tiket dibuka, kegagalannya terjadi di depan puluhan ribu suporter dan langsung jadi percakapan publik. Bukan sesuatu yang bisa diperbaiki diam-diam di rilis berikutnya.

PT Awan Dinata Teknologi datang ke kami dengan persoalan itu.

Kondisi sebelum bekerja sama dengan Casa5

Seluruh platform berjalan di perangkat keras milik sendiri, di lokasi fisik.

Perlu ditegaskan, ini bukan setup yang buruk. Tim di baliknya sudah menerapkan praktik pengembangan yang matang. Persoalannya bukan pada kualitas rancangan, melainkan pada keterbatasan yang melekat pada fondasi fisik.

Kapasitas harus dibeli untuk kondisi paling ramai

Perangkat keras diadakan berdasarkan puncak trafik yang mungkin terjadi. Akibatnya, di luar hari penjualan tiket, sebagian besar kapasitas itu menganggur. Dan tetap dibayar.

Tidak ada tombol untuk menambah kapasitas seketika

Ketika lonjakan datang lebih besar dari perkiraan, tidak ada yang bisa dilakukan saat itu juga. Menambah kapasitas berarti pengadaan, pemasangan, dan waktu berminggu-minggu.

Ketahanan sulit dan mahal diwujudkan

Membangun lapisan cadangan di infrastruktur fisik berarti menggandakan belanja perangkat keras. Buat banyak perusahaan, ujungnya risiko itu akhirnya cuma ditanggung dan didoakan tidak terjadi.

Setiap komponen dirawat sendiri

Basis data, sistem antrean, penyimpanan, lapisan cache, semuanya jadi tanggung jawab pemeliharaan tim internal. Waktu yang habis di sana adalah waktu yang tidak dipakai memperbaiki pengalaman pembeli tiket.

Merancang cloud untuk lonjakan trafik: cara Casa5 mengerjakannya

Kami menegaskan satu hal sejak awal: ini bukan sekadar memindahkan sistem, ini perjalanan adopsi cloud.

Bedanya penting. Memindahkan apa adanya cuma menghasilkan masalah yang sama di tempat berbeda, kapasitas tetap kaku dan pemeliharaan tetap manual. Adopsi cloud berarti mengganti komponen yang selama ini dirawat sendiri dengan layanan terkelola, sehingga beban operasionalnya betul-betul berpindah.

Tiga sasaran yang disepakati di awal

1. Kapasitas yang mengikuti permintaan, bukan kapasitas yang ditebak di depan
2. Ketahanan yang terpasang sebagai bawaan, bukan sebagai proyek tambahan
3. Biaya yang ditinjau ulang dari nol, mencari alternatif lebih efisien tanpa mengorbankan performa dan keamanan

Ada satu sasaran jangka panjang lagi: menyiapkan fondasi supaya siap menampung kapabilitas berbasis AI di masa depan.

Ketiga sasaran itu yang kemudian menentukan bentuk akhir rancangannya. Cloud untuk lonjakan trafik hanya bekerja kalau elastisitasnya memang dipakai, bukan sekadar tersedia.

Yang tidak diubah juga sebuah keputusan

Kami sengaja mempertahankan cara kerja tim dalam merilis dan memantau sistem.

Perubahan besar sebaiknya terjadi di lapisan fondasi, bukan di kebiasaan kerja harian tim engineering. Transformasi yang memaksa semua orang belajar ulang dari nol punya risiko gagal di tengah jalan yang jauh lebih tinggi.

Pengujian performa jadi syarat kelulusan cloud untuk lonjakan trafik

Untuk sistem ticketing, memastikan semuanya berfungsi saja tidak cukup. Proyek baru dinyatakan siap setelah lulus pengujian fungsional, pengujian keamanan, dan pengujian performa.

Cadangan dan peringatan dini masuk definisi “selesai”

Bukan pekerjaan susulan yang dijadwalkan entah kapan, tapi bagian dari kelengkapan proyek sebelum serah terima.

Seluruh rangkaian ini dituntaskan dalam tiga minggu.

Sebelum dan sesudah: apa yang benar-benar berubah

Yang tertinggal setelah proyek selesai

Perubahan terbesar buat PT Awan Dinata Teknologi bukan soal teknologinya. Yang hilang adalah satu kekhawatiran yang dulu berulang setiap kali tiket dibuka.

Sebelumnya, tiap pembukaan penjualan adalah taruhan: kapasitas yang disiapkan cukup atau tidak? Sekarang pertanyaan itu tidak lagi relevan, karena kapasitas mengikuti permintaan.

Biaya bergeser dari belanja besar di muka menjadi pengeluaran yang sebanding pemakaian. Buat pembanding, pergeseran serupa terjadi pada klien commerce kami di studi kasus migrasi cloud tanpa downtime Evermos, walaupun pemicunya berbeda. Dan waktu tim yang dulu habis merawat perangkat kembali ke tempat seharusnya, yaitu memperbaiki pengalaman suporter yang membeli tiket.

Seperti pendampingan Casa5 lainnya, kombinasi program pendanaan mitra dan investasi Casa5 membuat biaya jasa profesional bagi klien nol.

Pertanyaan yang sering muncul

Kenapa server sering down saat penjualan tiket dibuka? Karena kapasitasnya tetap, sementara permintaannya tidak. Sistem yang cukup untuk hari biasa bisa kewalahan dalam hitungan detik ketika puluhan ribu orang masuk bersamaan.

Apakah cloud otomatis menyelesaikan masalah lonjakan trafik? Tidak otomatis, dan ini sering disalahpahami. Cloud menyediakan kemampuannya, tapi arsitekturnya harus dirancang untuk memakai kemampuan itu. Aplikasi yang dipindahkan apa adanya akan tetap tersendat.

Apakah pindah ke cloud pasti lebih murah? Tidak selalu, dan kami tidak pernah menjanjikan itu di awal. Yang berubah adalah pola biayanya, dari belanja di muka untuk kapasitas puncak menjadi pengeluaran yang mengikuti pemakaian. Untuk beban kerja dengan pola lonjakan ekstrem, pergeseran ini biasanya memang berujung lebih hemat.

Pola lonjakan ekstrem tidak cuma milik penjualan tiket. Flash sale, pendaftaran serentak, dan rilis produk terbatas punya karakter yang sama. Casa5 merancang infrastruktur cloud yang elastis sekaligus hemat untuk pola seperti itu. Ceritakan kebutuhan Anda lewat halaman kontak.