IWAG

Hari Pertama Registrasi IWAG 2025: Behind the Scenes

Intip ke ruangan staf waktu semuanya berantakan.

Posted by

IWAG Staff's Avatar

IWAG Staff

Published at

Header image by @REORENADE
Header image oleh @REORENADE

Halo!

Kita mau mulai dengan ngucapin terima kasih banget buat kesabaran dan dukungannya pas pembukaan penjualan tiket tanggal 4 Januari 2025 kemarin malam yang sempat penuh drama. Sekarang semuanya udah balik normal dan website Community udah lancar lagi, kita mau share cerita behind the scenes tentang apa yang terjadi dan gimana kita ngatasinnya.

Di post ini, kita bakal jelasin langkah-langkah yang kita ambil buat identifikasi, benerin, dan stabilin masalah yang muncul. Kita bakal bahas sedikit detail teknis juga, tapi jangan khawatir, bakal kita buat semudah mungkin buat dimengerti. Yuk, langsung aja!

Apa yang Terjadi?

Buat ngejelasin apa yang salah, kita harus kasih gambaran dulu tentang cara kerja website Community. Ada empat bagian utama yang terlibat:

Community System
  1. Frontend (FE): Ini bagian website yang kamu lihat dan pakai, tempat beli event pass IWAG dan atur data kamu.
  2. Backend (BE): Yang ini ngurus semua kerjaan di balik layar, kayak proses pembelian dan mastiin pembayaran lancar.
  3. Single Sign-On (SSO): Layanan ini ngurus akun kamu, termasuk registrasi, login, dan update profil.
  4. Database (DB): Tempat semua informasi penting disimpan, kayak profil, riwayat transaksi, dan detail event pass kamu.

Pas kamu pakai website (misalnya klik tombol “Register Now”), request kamu bakal lewat sistem namanya Load Balancer (LB). Anggap aja ini kayak lampu lalu lintas yang ngatur arus mobil (request kamu) biar nggak macet. Load Balancer ini ngarahin request ke server yang beda-beda supaya nggak ada server yang kebebanan. Jadi, semuanya tetap lancar walaupun traffic lagi rame banget.

Detik-detik Kejadian

Sekarang kamu udah ngerti konteksnya, yuk kita liat step by step apa yang terjadi malam itu:

  • 19:45 (UTC+7): Tim tech kita bikin “War Room” buat mantau proses registrasi Event Pass. Ada yang ikut langsung di lokasi, ada juga yang remote, buat pastiin server aman terkendali.

  • 20:00 (UTC+7): Pengguna dan staf mulai notice ada masalah: website jadi super lemot, pesan “Internal Server Error (500)” dan “Bad Gateway (502)” nongol. Halaman checkout jadi susah banget dibuka, apalagi buat beli Event Pass.

  • 20:20 (UTC+7): Kita berhasil identifikasi masalah utama pertama: database locking. Database kita terlalu strict pas ngatur transaksi satu per satu, bikin semuanya jadi lambat. Perbaikan cepat kita lakuin buat bikin aturan ini lebih santai.

  • 20:35 (UTC+7): Walaupun masalah database udah diatasi, error 500 dan 502 masih muncul. Kita mikir ini gara-gara traffic yang berat banget, jadi kita tambahin kapasitas layanan frontend (FE) dan backend (BE) biar bisa nampung lebih banyak user. Kita juga mutusin buat nunda penjualan Event Pass ke jam 21:00 (UTC+7) buat kasih waktu stabilin sistem.

  • 20:50 (UTC+7): Dengan tambahan server, sistem kelihatan lebih stabil, walaupun Load Balancer (LB) masih ngos-ngosan. Kita siap-siap buat pembukaan penjualan berikutnya.

  • 21:00–21:40 (UTC+7): Begitu penjualan dibuka lagi, error 500 dan 502 muncul lagi. Tim langsung nambahin kapasitas layanan FE dan BE sambil ngelakuin analisis log buat nyari masalah lebih dalam. Penjualan ditunda dua kali, pertama ke jam 21:30 (UTC+7), lalu ke 22:00 (UTC+7).

  • 21:55 (UTC+7): Error muncul lagi saat traffic makin ramai. Kali ini, kita mutusin untuk tetap biarin registrasi terbuka supaya bisa ngumpulin lebih banyak log, yang nantinya bisa ngebantu nemuin sumber gara-gara.

  • 22:30 (UTC+7): Ada lonjakan permintaan ke layanan single sign-on (SSO) yang ketahuan. Sistem kewalahan karena banyak permintaan “refresh token” (yang dipakai untuk ngejagain pengguna tetap login). Kita sempat kepikiran buat bypass proses ini sementara, tapi akhirnya kita putusin buat menambah kapasitas server SSO biar bisa menangani beban.

  • 23:30 (UTC+7): Meski kapasitas server SSO udah ditingkatkan, masalahnya nggak hilang. Akhirnya kita sadar kalau masalahnya bukan cuma soal kapasitas, tapi juga gimana permintaan ini diarahkan. Tim mutusin untuk bagi Load Balancer (LB) jadi dua: satu untuk instance BE dan satu lagi untuk server SSO.

  • 23:45 (UTC+7): Kita mulai proses misahin Load Balancer.

  • 00:10 (UTC+7): Pemisahan selesai. Sebagai langkah pencegahan, semua pengguna di-log out lewat panel admin server SSO buat ngurangin beban.

  • 00:20 (UTC+7): Setelah memantau sistem selama 10 menit, error berhenti. Semua layanan stabil dan kembali normal.

Apa yang Kita Lakuin Buat Memperbaikinya

Berikut langkah-langkah utama yang kita ambil buat mengatasi masalah:

  1. Perbaikan Database: Setelah insiden IWAG 2024, di mana Pearl Pass terjual lebih dari kapasitas, transaksi kita buat lebih ketat supaya nggak ada transaksi ganda di event lain. Tapi kali ini, kita harus nyesuaiin lagi supaya transaksi nggak bikin database terkunci.

  2. Penambahan Kapasitas Layanan:

    • Nambahin kapasitas instance FE dan BE biar bisa nanganin permintaan yang tinggi.
    • Ningkatin kapasitas server SSO buat ngadepin lonjakan permintaan login.

  3. Penyesuaian Load Balancer: Misahin Load Balancer untuk layanan BE dan SSO supaya traffic bisa diatur lebih efisien.

  4. Manajemen Sesi: Semua pengguna di-log out sebagai langkah aman untuk mengurangi beban layanan SSO.

Setelah perubahan di Load Balancer, arsitektur kita sedikit berubah. Ini dia diagram arsitektur terbaru yang lebih simpel:

Community System

Gimana Proses Login Bekerja

Buat ngerti masalahnya, yuk kita bahas sedikit tentang gimana proses autentikasi (login dan logout) bekerja.

Penyedia single sign-on (SSO) kita pakai OAuth 2.0, standar yang sering dipakai buat autentikasi pengguna. Kalau kamu pernah klik “Sign in with Google” di website, berarti kamu udah pernah pakai OAuth 2.0! Standar ini mastiin pengguna bisa login dengan aman tanpa perlu terus-terusan masukin kredensial (username dan password) di setiap layanan.

Berikut penjelasan simpel tentang gimana prosesnya saat kamu login ke website Community:

Community System
  1. Kamu masukin kredensial kamu (kayak email dan password) di halaman login.
    • Frontend (FE) ngirim kredensial ini ke SSO Provider.
  2. SSO Provider ngecek kredensial kamu dan ngasih balik dua token penting:
    • Access Token: Dipakai buat buktiin kalau kamu udah login untuk aksi tertentu (contoh: daftar Event Pass).
    • Refresh Token: Dipakai buat dapetin Access Token baru tanpa harus login lagi.

Token ini sebenarnya cuma kumpulan angka dan huruf random yang dibuat mesin. Dengan token ini, kamu resmi login dan bisa ngelakuin berbagai hal di website.

Access Token punya masa berlaku yang singkat demi alasan keamanan. Ini cara sistem menjaga sesi kamu tetap aktif tanpa harus login ulang:

  1. Pas Access Token habis masa berlakunya, FE ngirim Refresh Token ke SSO Provider buat minta Access Token baru.
  2. SSO Provider ngasih balik Access Token baru sekaligus Refresh Token baru.
  3. Proses ini terjadi di belakang layar, jadi kamu tetap login tanpa hambatan.

Apa yang Salah

Masalahnya datang dari alur Refresh Token, yang sebenarnya dirancang buat menjaga pengguna tetap login. Tapi ada beberapa hal yang bikin kacau:

  1. SSO Kewalahan:

    • Server SSO kewalahan karena mendadak ada lonjakan permintaan, terutama dari pengguna yang buka atau refresh halaman Event dan checkout.
    • Server nggak sanggup menangani semua permintaan dan mulai error.

  2. Retry Otomatis:

    • Pas FE nggak dapet respon dari SSO, FE otomatis ngulang permintaan.
    • Ini bikin lingkaran setan di mana permintaan yang gagal malah nambah beban ke SSO yang udah struggling.

  3. Token Nggak Valid:

    • SSO Provider mulai invalidasi Refresh Token sebelum waktunya, dan ini bikin masalah makin rumit.
    • FE nggak sadar kalau Refresh Token yang dikirim udah nggak valid, dan ini memperparah siklusnya.

Pelajaran yang Kita Ambil

Berikut beberapa hal penting yang kita pelajari biar kejadian kayak gini nggak terulang:

  1. Fokus ke Skalabilitas: Scaling sistem kita masih manual, yang bikin ribet di platform dengan demand yang fluktuatif kayak Community. Investasi di infrastruktur yang lebih canggih bisa bantu scaling lebih gampang.

  2. Perbaiki Load Testing: Sebelum event besar, kita udah coba load testing, tapi ada bagian yang masih perlu ditingkatkan biar lebih mendekati situasi nyata.

  3. Token yang Lebih Lama Masa Berlaku: Access Token yang kita pakai punya masa berlaku singkat karena sifat transaksi kita yang cepat. Kalau sesi bisa lebih panjang sedikit, beban ke SSO bakal lebih ringan.

  4. Pisahin Layanan dengan Traffic Tinggi: Memisahkan Load Balancer untuk BE dan SSO mastiin mereka nggak saling berebut sumber daya pas load tinggi, jadi nggak ada masalah berantai kalau salah satu layanan krusial error.

  5. Tingkatkan Logging dan Monitoring: Kita bisa deteksi masalah lewat log request. Kalau akses ke alat logging dan monitoring dibuka buat seluruh tim tech, deteksi masalah bisa lebih cepat.

Dampaknya ke Rilis Sponsor Tier

Setelah investigasi dan perbaikan selesai, kita mau mastiin sistem kita siap menghadapi beban berat lagi secara terkendali. Makanya kita memutuskan buat nunda penjualan Pioneer dan Guardian event pass ke 11 Januari 2025, dalam dua batch, supaya kita bisa pantau performa sistem dan mastiin semuanya aman.

Ke depannya, tim registrasi kita bakal terus evaluasi gimana cara terbaik buat ngerilis tier pass yang lebih tinggi sambil mempertimbangkan kesiapan sistem kita.