Memilih Arsitektur Game Event Web: Monolit atau Microservices?

Saat membangun web app event mini-game seperti bingo musiman, pertanyaan monolit atau microservices biasanya muncul terlalu cepat. Untuk kebanyakan tim kecil, jawaban praktisnya adalah: mulai dari monolit modular, tambah worker dan queue untuk pekerjaan asinkron, lalu pertimbangkan microservices hanya jika ada batas organisasi atau teknis yang benar-benar terasa.

Masalah utama pada game event web bukan hanya throughput, tetapi kombinasi dari lonjakan traffic singkat, fitur interaktif seperti papan bingo dan skor, operasional sederhana, serta kebutuhan rilis cepat untuk konten musiman. Arsitektur yang terlalu terpecah memang bisa tampak “siap skala”, tetapi sering menambah latency, biaya cloud, kompleksitas deployment, dan beban debugging tanpa manfaat yang sebanding.

Karakteristik sistem: game event mini-game tidak sama dengan produk SaaS umum

Contoh konteksnya adalah aplikasi event ringan dengan fitur seperti:

• Login pengguna melalui email, OAuth, atau magic link.
• Papan bingo yang menyimpan progress per user.
• Skor, badge, atau leaderboard sederhana.
• Notifikasi email, push, atau in-app.
• Admin konten untuk mengubah tema, daftar tantangan, periode event, dan hadiah.

Beban sistem seperti ini biasanya punya pola yang khas:

• Traffic naik tajam saat event dimulai atau dipromosikan.
• Sebagian besar operasi adalah read-heavy: baca papan, progress, daftar task, leaderboard.
• Beberapa operasi butuh konsistensi cukup baik, misalnya claim reward dan update skor.
• Fitur admin butuh cepat diubah, tetapi tidak selalu high-throughput.
• Tim sering kecil, jadi biaya koordinasi antar-service bisa lebih mahal daripada biaya CPU.

Karena itu, keputusan arsitektur sebaiknya mengikuti bentuk masalah nyata, bukan mengikuti pola arsitektur yang sedang populer.

Tiga opsi arsitektur yang realistis

1. Monolit modular

Semua fitur berjalan dalam satu aplikasi dan satu deployment utama, tetapi dipisah jelas secara modul: auth, bingo, scoring, notification, admin, dan lain-lain.

Kelebihan:

• Deployment paling sederhana.
• Latency antar modul rendah karena masih in-process atau dalam satu database.
• Debugging lebih mudah karena jejak request tidak lintas service.
• Biaya cloud umumnya lebih hemat pada tahap awal.
• Sangat cocok untuk tim kecil yang ingin bergerak cepat.

Kekurangan:

• Jika struktur kode buruk, aplikasi cepat menjadi “bola lumpur” (big ball of mud).
• Scaling biasanya dilakukan pada seluruh aplikasi, bukan hanya bagian yang panas.
• Batch job atau notifikasi bisa mengganggu request utama jika tidak dipisah dengan worker.

2. Backend + worker + queue

Ini sering menjadi titik tengah terbaik. API utama tetap monolit modular, tetapi pekerjaan lambat atau bursty dipindahkan ke worker melalui queue.

Contoh tugas yang cocok dijadikan async:

• Mengirim email notifikasi.
• Menghitung ulang leaderboard berkala.
• Membuat ringkasan statistik admin.
• Sinkronisasi ke sistem analitik.
• Proses anti-cheat ringan atau validasi non-kritis.

Kelebihan:

• Meningkatkan respons request utama.
• Lebih mudah menangani spike traffic.
• Tetap sederhana dibanding microservices penuh.
• Memudahkan retry untuk task yang gagal.

Kekurangan:

• Menambah kompleksitas operasional: queue, worker process, retry, dead-letter policy.
• Harus menerima eventual consistency pada beberapa fitur.
• Butuh observability yang lebih baik agar job gagal tidak diam-diam menumpuk.

3. Microservices

Setiap domain besar berjalan sebagai service terpisah, misalnya auth service, game board service, scoring service, notification service, dan admin content service.

Kelebihan:

• Bisa scale per service jika beban sangat berbeda.
• Boundary domain lebih tegas bila tim juga sudah terpisah.
• Teknologi per service bisa berbeda bila memang ada alasan kuat.

Kekurangan:

• Deployment, network, observability, dan keamanan jauh lebih kompleks.
• Latency naik karena komunikasi antar-service.
• Konsistensi data menjadi lebih sulit, terutama untuk skor, reward, dan status claim.
• Biaya cloud naik karena setiap service butuh runtime, monitoring, secret, autoscaling, dan pipeline sendiri.
• Tidak efisien untuk tim kecil yang mengelola fitur musiman dengan waktu pengembangan singkat.

Tabel keputusan: pilih arsitektur berdasarkan kondisi nyata

Rekomendasi default untuk web app bingo musiman

Untuk aplikasi event mini-game dengan fitur login, papan bingo, skor, notifikasi, dan admin konten, default yang sehat biasanya seperti ini:

• Satu backend modular untuk API dan admin.
• Satu database relasional sebagai sumber data utama.
• Redis atau cache sejenis untuk session, cache read-heavy, rate limit, dan queue backend bila diperlukan.
• Worker terpisah untuk notifikasi, rekap skor, dan tugas non-interaktif.
• Object storage/CDN untuk aset statis event.

Susunan ini sering cukup untuk menangani kebutuhan nyata tanpa membuat sistem sulit dioperasikan. Secara konseptual:

Browser / Mobile Web
        |
     CDN / WAF
        |
   Web App Backend
  (auth, bingo, score,
   admin, API)
     /        \
Database     Redis/Cache
                |
              Queue
                |
              Worker
        (email, push, leaderboard rebuild)

Pola ini bekerja karena request yang sensitif terhadap latency tetap langsung ke backend, sementara pekerjaan lambat dipisah. Anda mendapatkan manfaat skalabilitas awal tanpa membayar kompleksitas microservices penuh.

Memetakan fitur ke batas arsitektur

Login

Simpan di backend utama kecuali Anda memang sudah memiliki platform identity terpisah. Login menyentuh session, cookie, rate limit, audit log, dan kadang profil user. Memecah auth terlalu awal sering menambah kerumitan karena hampir semua fitur bergantung padanya.

Hal yang perlu diperhatikan:

• Gunakan session store atau token secara konsisten.
• Terapkan rate limiting untuk login dan magic link.
• Pastikan secret management dan rotasi token jelas.

Papan bingo

Biasanya ini adalah domain inti dan sebaiknya tetap dekat dengan database utama. Operasi umum seperti mark square, baca progress, dan render board lebih mudah dijaga konsistensinya bila berada dalam satu boundary aplikasi.

Jika setiap klik mengubah state game, gunakan transaksi sederhana dan idempotensi untuk mencegah update ganda akibat retry dari client.

Skor dan leaderboard

Ini sering menjadi sumber salah desain. Banyak tim langsung memecah “scoring service”, padahal masalah utamanya sering hanya agregasi yang mahal, bukan kebutuhan service terpisah.

Pendekatan yang lebih aman:

• Simpan event atau perubahan skor di database utama.
• Hitung leaderboard secara inkremental atau berkala via worker.
• Cache hasil leaderboard dengan TTL pendek atau invalidasi berbasis event.

Dengan ini, write path tetap sederhana, sementara read path untuk halaman populer menjadi ringan.

Notifikasi

Ini kandidat kuat untuk async. Pengiriman email atau push tidak perlu memblok request user. Gunakan queue dan worker, lalu desain job agar idempotent karena pengiriman ulang bisa terjadi.

Admin konten

Untuk aplikasi musiman, panel admin sering lebih penting daripada yang diperkirakan. Tetap di monolit biasanya memudahkan karena model data konten, bingo card, rules event, dan status publish ada di tempat yang sama. Jika konten dibaca sering, pasang cache di layer read atau CDN untuk aset.

Skalabilitas: yang perlu di-scale biasanya bukan semuanya

Argumen umum untuk microservices adalah “lebih mudah scale”. Itu benar hanya jika bottleneck Anda memang terlokalisasi dan cukup besar untuk membenarkan pemisahan. Pada game event web, bottleneck yang lebih sering adalah:

• Query leaderboard yang berat.
• Render halaman dengan banyak komponen dinamis.
• Lonjakan login saat kampanye dimulai.
• Pengiriman notifikasi massal.
• Cache miss besar setelah deploy atau invalidasi global.

Semua masalah itu sering bisa ditangani tanpa microservices:

• Leaderboard berat → precompute dengan worker, materialized table, atau cache.
• Lonjakan login → rate limit, session cache, tuning DB index.
• Notifikasi massal → queue + batch processing.
• Read-heavy board → cache hasil query atau fragment render.

Prinsip praktis: jika bottleneck bisa dijelaskan pada level query, cache, job, atau resource pool, maka solusi pertama biasanya bukan memecah service.

Latency dan konsistensi data: microservices sering membuat masalah inti lebih sulit

Dalam game event, pengguna cepat melihat bila state terasa aneh: kotak bingo tercatat tetapi skor belum berubah, reward muncul dua kali, atau leaderboard tertinggal lama. Ini adalah area di mana microservices sering memperparah keadaan.

Mengapa?

• Request lintas service menambah hop jaringan dan titik gagal.
• Transaksi lintas database tidak sederhana dan sering dihindari.
• Event-driven flow butuh idempotensi, deduplikasi, urutan event, dan retry policy.

Contoh kasus: user menandai satu kotak bingo yang seharusnya:

1. Menyimpan progress board.
2. Menambah skor.
3. Mengecek apakah satu baris penuh.
4. Mengirim notifikasi hadiah.

Dalam monolit modular, langkah 1-3 bisa selesai dalam satu boundary transaksi, lalu langkah 4 dikirim ke queue setelah commit berhasil. Dalam microservices, Anda perlu memikirkan koreografi event, kegagalan parsial, dan recovery state antar-service.

Itu bukan berarti microservices salah, tetapi biaya kognitifnya tinggi. Untuk tim kecil, menjaga satu sumber kebenaran data sering lebih bernilai daripada distribusi komponen.

Observability dan debugging: faktor yang sering diremehkan

Semakin terdistribusi sistem Anda, semakin mahal biaya untuk memahami apa yang sedang terjadi. Pada monolit, satu request biasanya bisa dilacak melalui satu log stream dan satu APM service. Pada microservices, satu aksi user bisa melintasi beberapa service, queue, cache, dan callback pihak ketiga.

Minimal, apa pun arsitekturnya, siapkan:

• Structured logging dengan request ID/correlation ID.
• Metrics untuk latency, error rate, queue depth, retry count, dan DB slow query.
• Tracing jika sudah ada worker atau service terpisah.
• Dashboard operasional untuk leaderboard lag, job failure, dan notification throughput.

Pada banyak kasus, tim merasa “butuh microservices” padahal sebenarnya mereka “butuh observability yang lebih baik”.

Biaya cloud dan biaya operasional tim kecil

Biaya bukan hanya tagihan compute. Arsitektur yang lebih terpecah juga menambah biaya berikut:

• Lebih banyak instance atau container.
• Lebih banyak pipeline CI/CD.
• Lebih banyak secret, network policy, dan TLS endpoint.
• Lebih banyak komponen monitoring dan alerting.
• Lebih banyak waktu engineer untuk on-call dan investigasi.

Untuk aplikasi event musiman, pola traffic sering tidak stabil. Jika sistem Anda terdiri dari banyak service kecil, Anda berisiko membayar idle cost saat event sepi, lalu tetap menghadapi tuning yang rumit saat event ramai.

Monolit modular dengan worker biasanya memberi rasio terbaik antara performa dan biaya operasional, terutama jika deployment dapat di-scale horizontal dan proses worker bisa dinaikkan terpisah dari web node.

Kapan tetap monolit, kapan menambah queue/cache, kapan baru mempertimbangkan microservices

Sinyal untuk tetap monolit modular

• Tim masih kecil dan tidak punya owner tetap per domain.
• Perubahan fitur sering menyentuh auth, board, score, dan admin sekaligus.
• Sumber masalah utama masih di query, indexing, atau caching.
• Anda belum punya kebutuhan compliance atau isolasi service yang ketat.
• Deployment tunggal masih cepat, stabil, dan mudah di-roll back.

Sinyal untuk menambah queue dan cache

• Request user melambat karena kirim email, push, atau job turunan lain.
• Leaderboard atau halaman populer membaca agregasi berat berulang kali.
• Spike traffic menyebabkan database kewalahan pada operasi read.
• Anda butuh retry otomatis untuk integrasi pihak ketiga.
• Waktu respons membaik signifikan jika pekerjaan non-kritis dipindah ke async.

Sinyal untuk mulai mempertimbangkan microservices

• Satu domain punya pola scaling yang sangat berbeda dan terus-menerus.
• Batas domain sudah jelas dan relatif jarang berubah.
• Tim sudah cukup besar untuk ownership lintas service.
• Deployment monolit terlalu sering berbenturan antar tim.
• Kebutuhan isolasi keamanan atau reliabilitas per domain benar-benar penting.
• Observability, platform, CI/CD, dan incident response sudah matang.

Anti-pattern: memecah service terlalu cepat

Beberapa pola berikut sering terlihat pada proyek event app yang belum cukup besar untuk microservices:

1. Auth service dipisah padahal hanya dipakai satu aplikasi

Akibatnya, login, session, profile, dan permission tersebar. Setiap perubahan kecil butuh koordinasi antar-repo dan antar-deployment.

2. Scoring service dibuat hanya karena leaderboard terasa lambat

Masalah sebenarnya mungkin query agregasi buruk atau tidak ada cache. Memecah service tidak otomatis mempercepat query.

3. Notification service sinkron di request path

Service-nya terpisah, tetapi masih dipanggil langsung saat user submit aksi. Hasilnya tetap lambat, hanya sekarang juga lebih rapuh.

4. Satu database per service sejak awal tanpa alasan kuat

Ini membuat join data bisnis menjadi sulit, reporting rumit, dan konsistensi antar-domain lebih mahal dari yang dibayangkan.

5. Event-driven untuk semua hal, termasuk yang butuh konsistensi langsung

Tidak semua operasi cocok menjadi eventual consistency. Progress board dan reward claim biasanya perlu state yang mudah dipahami pengguna saat itu juga.

Contoh implementasi praktis: monolit modular + worker

Misalnya saat user menyelesaikan satu kotak bingo. Jalur yang aman biasanya seperti ini:

1. Backend memvalidasi user dan periode event.
2. Backend menyimpan perubahan progress dalam transaksi.
3. Backend menghitung update skor inti yang harus konsisten saat itu juga.
4. Setelah commit sukses, backend menerbitkan job async untuk notifikasi atau rekap leaderboard.

// Pseudocode, framework-agnostic
function markBingoSquare(userId, squareId) {
  beginTransaction();

  const board = boardRepo.lockByUser(userId);
  if (board.isMarked(squareId)) {
    commit();
    return { ok: true, idempotent: true };
  }

  board.mark(squareId);
  scoreRepo.addPoints(userId, 10);

  const completedLine = board.checkCompletedLine();
  if (completedLine) {
    rewardRepo.grantIfNotExists(userId, completedLine.rewardCode);
  }

  commit();

  queue.publish('bingo.square_marked', {
    userId,
    squareId,
    completedLine: !!completedLine
  });

  return { ok: true };
}

Yang penting di sini:

• Idempotensi: klik ganda atau retry tidak memberi poin dua kali.
• Transaksi lokal: state inti selesai konsisten sebelum job async dijalankan.
• Async setelah commit: notifikasi tidak boleh terkirim jika transaksi utama gagal.

Praktik maintainability untuk monolit agar tidak berubah menjadi kacau

Banyak tim takut monolit karena pengalaman buruk dengan codebase besar. Masalahnya biasanya bukan “monolit”, melainkan monolit tanpa boundary internal.

Beberapa praktik yang membantu:

• Pisahkan modul berdasarkan domain, bukan hanya folder teknis.
• Batasi akses langsung antar-modul melalui service/repository yang jelas.
• Gunakan migration, schema, dan naming yang konsisten.
• Tulis test pada level domain untuk aturan bingo, reward, dan scoring.
• Dokumentasikan event internal dan job queue yang penting.
• Hindari menjadikan controller sebagai tempat seluruh logika bisnis.

Jika monolit tertata, migrasi ke service terpisah di masa depan juga lebih mudah karena batas domain sudah ada sejak awal di level kode.

Checklist keputusan singkat

• Apakah tim Anda kecil dan butuh cepat rilis? Pilih monolit modular.
• Apakah request utama lambat karena tugas sampingan? Tambah queue + worker.
• Apakah halaman populer read-heavy? Tambah cache dan precompute.
• Apakah bottleneck benar-benar spesifik per domain dan berlangsung terus? Evaluasi pemisahan service.
• Apakah Anda sudah siap dengan tracing, alerting, contract testing, dan ownership lintas tim? Jika belum, jangan buru-buru microservices.

Kesimpulan

Untuk kebanyakan arsitektur game event web seperti aplikasi bingo musiman, pilihan paling masuk akal adalah monolit modular yang ditopang queue, worker, dan cache saat kebutuhan meningkat. Pendekatan ini memberi latency rendah, konsistensi data yang lebih mudah, deployment sederhana, dan biaya cloud yang lebih terkendali.

Microservices baru layak ketika Anda punya alasan yang lebih kuat daripada sekadar antisipasi skala: domain stabil, tim terpisah, pola scaling sangat berbeda, dan platform operasional sudah matang. Sebelum sampai ke sana, optimalkan boundary internal, query, cache, dan proses async. Untuk web app event mini-game, itu biasanya memberi hasil terbaik dengan risiko paling rendah.