Setelah AI mempercepat pembuatan aplikasi, bahaya berikutnya adalah merasa “sudah selesai”
Dengan AI, aplikasi multiplayer bisa jadi sangat cepat. Room bisa dibuat, pengguna masuk, kirim konten, lalu voting. Otak langsung berkata:
Selesai.
Server menjawab:
Tadi kamu cuma mengetes satu orang.
Pertanyaan penting justru datang setelah itu. Bagaimana kalau 100 orang menekan tombol bersamaan? Bagaimana jika database sudah menyimpan tetapi respons sukses hilang? Bagaimana kalau vote terakhir datang tepat saat deadline? Bagaimana jika notifikasi pembayaran masuk dua kali? Bagaimana kalau semua pengguna reconnect bersamaan setelah gangguan?
Review kode sebuah aplikasi multiplayer kecil berkembang menjadi 324 skenario pengujian. Itu bukan berarti ada 324 bug. Semua masih belum dijalankan. Itu rencana pengujian, bukan bukti lulus.
1. DDoS bukan satu-satunya masalah
Cloudflare menyediakan mitigasi DDoS otomatis untuk semua paket, tetapi tetap menyarankan perlindungan tingkat aplikasi seperti rate limiting karena serangan besar masih bisa berdampak pada aplikasi.[1]
Pada aplikasi kecil, trafik normal pun bisa menjadi masalah pertama.
Jika klien mengecek status setiap 3 detik:
| Perangkat bersamaan | Cek status per jam |
|---|---|
| 10 | 12.000 |
| 30 | 36.000 |
| 100 | 120.000 |
| 1.000 | 1.200.000 |
Ini bukan ramalan kapasitas nyata. Backoff dan cache bisa mengurangi; posting, gambar, inbox, banyak tab, dan pekerjaan terjadwal bisa menambah.
Per 5 Oktober 2026, Workers Free mencantumkan 100.000 request per hari. D1 Free mencantumkan 5 juta row read per hari, 100.000 row write per hari, 500 MB per database, dan 50 query per invokasi Worker.[2][3] Satu database D1 memproses query satu per satu; terlalu banyak permintaan bersamaan akan mengantre dan akhirnya bisa menghasilkan error overloaded.[3]
Jadi bukan hanya “satu juta penyerang” yang menakutkan.
Seratus pengguna normal yang bermain bersamaan juga bisa menjadi load test.
2. Mengapa daftar menjadi 324 item
Ada 16 kelompok: pintu masuk dan abuse, kapasitas, concurrency dan recovery, pekerjaan terjadwal, room dan izin, gambar, teks, voting, deadline, hasil, room publik, koneksi persisten, perangkat dan reconnect, integrasi, pembayaran, serta deployment dan monitoring.
Kuncinya adalah prioritas.
3. 23 hal yang perlu dihantam lebih dulu
- Apakah request yang ditolak tetap memicu kerja database mahal?
- Apakah penghitung penggunaan internal benar-benar menghitung semua jalur mahal?
- Apakah rate limit bertahan setelah restart dan di banyak instance?
- Apakah polling “tidak ada perubahan” tetap membaca banyak data?
- Bisakah satu kursi membuka koneksi persisten tanpa batas?
- Apakah HTTP dan koneksi persisten memakai batas yang sama?
- Setelah emergency stop, apakah klien yang sudah terhubung juga berhenti?
- Jika scheduler terlambat, apakah aksi setelah deadline masih diterima?
- Jika satu efek gagal disimpan, apakah room tetap maju?
- Bisakah proses repair menggandakan statistik?
- Bisakah jatah mulai terpakai sebelum game benar-benar dibuat?
- Bisakah retry membuat satu jawaban menjadi dua?
- Bisakah variasi nama visual melewati aturan unik?
- Bisakah dua orang mengambil kursi terakhir bersamaan?
- Bisakah scheduled job menumpuk lebih cepat daripada diproses?
- Apakah ukuran seluruh database dan indeks dipantau, bukan hanya gambar?
- Bisakah orang lain mengambil identitas perangkat yang hilang?
- Apakah format, dimensi, metadata, dan lokasi gambar aman?
- Apakah histori panjang membuat setiap layar makin mahal?
- Bisakah reconnect serentak menyebabkan gangguan kedua?
- Sudahkah pembayaran duplikat, terlambat, gagal, batal, dan restore diuji?
- Apakah lulus test lokal disangka sama dengan lulus produksi?
- Jika database mati, apakah sistem monitoring ikut mati?
4. Bug suka kombinasi
Skenario bernilai tinggi:
100 orang vote → 20 refresh → 10 putus koneksi → beberapa write sukses tetapi respons hilang → retry.
Periksa vote ganda, vote terlambat, tampilan mundur ke state lama, atau operasi yang sama berjalan dua kali.
OWASP juga memisahkan concurrent sessions, input abnormal, dan error handling sebagai area pengujian.[4]
5. “Sudah tersimpan” dan “pengguna menerima sukses” berbeda
Server bisa berhasil menyimpan sementara respons jaringan hilang.
Pengguna mengira gagal lalu menekan lagi.
Tanpa operation ID atau mekanisme deduplikasi, bisa muncul dua jawaban, dua room, dua vote, dua notifikasi, bahkan dua tagihan.
Retry harus dirancang.
6. Load test naik bertahap
Di lingkungan yang kamu kendalikan: 10 → 30 → 100 klien.
Lalu ubah bentuk trafik: satu room padat, banyak room, join bersamaan, vote terakhir bersamaan, reconnect massal, scheduler bersamaan, dan kegagalan penyimpanan yang disengaja.
Jangan mengirim trafik besar ke sistem orang lain atau lingkungan tanpa izin. Tentukan anggaran dan kondisi berhenti sebelumnya.
7. “Tidak crash” belum berarti lulus
Target awal bisa 95% request normal di bawah 1 detik, 99% di bawah 3 detik, dan error 5xx tak terduga di bawah 0,1%.
Tetapi ini harus nol:
- data pengguna lain bocor;
- aksi tanpa izin;
- skor ganda;
- data yang sudah tersimpan hilang;
- tagihan ganda.
8. Desain test 9/10, bukti eksekusi 0/10 itu mungkin
Daftar 324 item dan 23 risiko prioritas bisa sangat bagus.
Namun sebelum dijalankan, bukti nyata masih nol.
Itu bukan kegagalan. Kamu sudah pindah dari “tidak tahu apa yang diuji” ke “tahu persis bagian mana yang harus dicoba rusak”.
9. Lalu yang lebih dulu habis bisa jadi kuota AI
Seharian meminta AI membaca repository besar, membuat fitur, memperbaiki, review, lalu mengulang bisa menghabiskan kuota AI sebelum server bermasalah.
Per 5 Oktober 2026, Claude Max 20x berharga US$200 per bulan di web. “20x” adalah kapasitas per sesi dibanding Pro. Batas sesi reset setiap lima jam, tetapi ada juga batas mingguan yang dipakai bersama semua model.[5]
20x bukan tak terbatas.
Penggunaan sebenarnya tergantung model, konteks, dan pekerjaan; lihat Settings > Usage.
10. “Fable mahal” juga terlihat dari angka
Pada Max, Fable 5 dan 5.1 tersedia, tetapi penggunaan Fable dapat memakai sampai 50% batas mingguan dan menurut Anthropic menghabiskan jatah lebih cepat daripada model Claude lain.[6]
| Model | Input / 1M token | Output / 1M token |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Harga input dan output Fable 5.1 adalah 2,5 kali Opus 5.5. Cache read yang lebih murah membuatnya lebih efisien daripada Fable 5, tetapi harga absolut tetap tinggi.[6][7][8]
Harga API tidak bisa langsung diubah menjadi menit kuota Max, tetapi arahnya jelas: model berat yang dijalankan lama tetap mahal.
11. Jangan pakai crane untuk setiap sekrup
Sonnet 5.5: perbaikan rutin, bug yang sudah dipahami, edit berulang, implementasi dengan ruang lingkup jelas.
Opus 5.5: akar masalah tidak jelas, perubahan arsitektur, review banyak file, keputusan penting sebelum rilis.
Fable 5.1: pekerjaan tersulit ketika kemampuan tambahan memang layak dibayar dengan biaya atau konsumsi kuota lebih tinggi.
Ini bukan ranking. Ini manajemen biaya per tugas.
12. AI memindahkan bottleneck
Dulu: ide → coding berminggu-minggu → testing.
Sekarang: ide → implementasi cepat → testing, operasi, batas server, dan batas AI datang bersamaan.
“Aku membuat app dalam satu hari” bisa benar.
Versi yang lebih tepat:
“Dalam satu hari, aku sampai ke tahap di mana app ini sudah layak dicoba dirusak dengan serius.”
Di situlah persiapan rilis benar-benar dimulai.
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
