Arena Card memasukkan pemain dengan id dan zona dalam gimnya, memverifikasinya dengan sebuah kode, lalu merender satu halaman berisi statistik ranked, sorotan pertandingan, hero yang paling sering dimainkan, dan pertandingan terbaru. Setiap panggilan ke API gimnya terjadi di server: peramban hanya pernah berbicara dengan aplikasi ini.
Satu halaman, satu tugas: menunjukkan kepada pemain seperti apa akunnya. Masuk memerlukan id dan zona dalam gim, mengirimkan kode verifikasi, lalu menukarnya dengan sebuah sesi. Setelah itu halamannya merender potret profil, statistik performa, sorotan pertandingan, hero yang paling sering dimainkan, dan pertandingan terbaru berhalaman lengkap dengan tampilan detail per pertandingan.
Ia adalah pasangan Arena Academy — API hulu yang sama, arsitektur yang berlawanan. Academy menyimpan sesi di peramban dan memanggil API dari sana; Arena Card menyimpan sesinya di sisi server dan mengirimkan HTML jadi ke peramban, dengan satu permintaan same-origin di balik tampilan detail pertandingan.
Tidak ada penyimpanan sesi, karena tidak ada yang layak disimpan antar permintaan yang terlalu besar untuk sebuah cookie. Middleware sesinya ditulis langsung terhadap antarmuka ASGI: payload-nya berupa JSON, dikodekan base64url dan ditandatangani dengan HMAC-SHA256 atas byte mentahnya, dibandingkan dalam waktu konstan, dengan usia maksimum satu hari serta HttpOnly, SameSite=Lax, dan Secure di luar mode debug.
Ditandatangani bukan berarti dienkripsi, dan desainnya menghormati perbedaan itu. Cookie-nya bersifat tamper-evident, bukan rahasia, sehingga ia membawa kredensial milik pemanggilnya sendiri dan tidak membawa apa pun tentang orang lain. Skrip di halaman tidak pernah menyentuhnya; token bearer-nya dilampirkan di sisi server pada setiap panggilan ke hulu.
Pesan sekilas, pengisian ulang formulir setelah pengiriman gagal, dan payload mentah terakhir untuk tampilan debug semuanya menumpang mekanisme yang sama, yang menjaga servernya tetap cukup stateless untuk berjalan di platform per-permintaan.
Dua mode kegagalan membentuk lapisan pengaturannya, dan keduanya benar-benar terjadi.
Konsol deployment yang mendeklarasikan sebuah variabel lalu membiarkan nilainya kosong meneruskan string kosong. Untuk pengaturan bertipe boolean atau bilangan bulat, itu bukan nilai yang hilang melainkan nilai yang tidak valid, dan validasinya gagal saat impor — sebelum aplikasinya ada untuk melaporkan sebabnya. Nilai kosong untuk pengaturan non-string sekarang dibuang sehingga nilai bawaannya berlaku.
Yang kedua adalah rebranding-nya. Setiap host API yang menjadi konfigurasi aplikasinya ditarik sekaligus, dan proses masuk rusak persis karena itu: nilai basi di sebuah konsol yang tak pernah ditengok lagi. Host yang sudah ditarik kini dipetakan maju pada titik pengaturannya dibaca, dengan host cadangan di belakang yang utama, sehingga nilai yang tidak pernah diperbarui siapa pun tetap mengarah ke sesuatu yang menjawab.