Arsitektur Simulasi Monte Carlo: Batch vs Real-Time & Biaya Skala

Engine prediksi turnamen berbasis simulasi Monte Carlo membutuhkan puluhan ribu iterasi acak per pertandingan untuk menghasilkan probabilitas agregat yang konvergen. Masalah fundamental dalam sistem ini adalah sifat beban kerja yang CPU-bound. Menjalankan 50.000 iterasi simulasi secara sinkron pada siklus request-response HTTP biasa akan menghabiskan resource CPU dan menyebabkan timeout seketika saat traffic melonjak.

Dua pendekatan arsitektur utama untuk menyelesaikan tantangan ini adalah Pre-computed Batch Pipeline dan On-Demand Real-Time Inference. Masing-masing memiliki implikasi teknis yang berbeda terhadap latensi, pemanfaatan resource, dan biaya infrastruktur cloud.

1. Pola Pre-computed Batch Pipeline

Pada pendekatan batch, simulasi dieksekusi secara periodik atau triggered oleh event tertentu (misalnya pertandingan selesai atau roster pemain diumumkan). Hasil simulasi diagregasi, dikonversi menjadi format JSON statis, lalu disimpan pada cache storage atau CDN.

+----------------------+      +------------------------+      +------------------+
| Event: Match Finished| ---> | Orchestrator (Temporal)| ---> | Worker Cluster   |
+----------------------+      +------------------------+      | (Multithreaded)  |
                                                              +--------+---------+
                                                                       |
                                                                  Run 100k Sims
                                                                       |
+----------------------+      +------------------------+               v
| User Request         | ---> | Edge CDN / Cache       | <---- [JSON Snapshot]
+----------------------+      | (TTL: 1 Jam)           |
                              +------------------------+

Pendekatan ini memisahkan total kalkulasi komputasi dari permintaan baca pengguna. Keuntungan utamanya:

• Latensi Sub-Milidetik: Pengguna hanya membaca data statis terkompresi dari edge layer (Cloudflare, Fastly, atau AWS CloudFront).
• Isolasi Beban: Lonjakan traffic saat pertandingan berlangsung tidak mempengaruhi utilisasi CPU worker kalkulasi.
• Efisiensi Komputasi: Simulasi hanya dihitung satu kali untuk seluruh audiens, terlepas dari apakah ada seratus atau sepuluh juta pengguna yang membaca hasilnya.

2. Pola On-Demand Real-Time Inference

Pola real-time dibutuhkan jika pengguna diizinkan memasukkan parameter variabel sendiri, seperti simulasi 'what-if' (misalnya memproyeksikan probabilitas jika pemain kunci cedera atau seed turnamen diubah secara manual).

+--------------+      +-------------+      +-------------------+      +-------------+
| User Request | ---> | API Gateway | ---> | Compute Workers   | ---> | Return JSON |
| (What-If)    |      +-------------+      | (Lambda/Spot Pod) |      | Response    |
+--------------+                           +-------------------+      +-------------+
                                                     |
                                            Run Dynamic Monte Carlo
                                            (Target: <500ms)

Tantangan utama pendekatan on-demand adalah latensi dan konkurensi compute:

• Cold Starts & CPU Throttle: Menjalankan simulasi intensif di Serverless FaaS (seperti AWS Lambda) rentan terkena pembatasan core CPU virtual, meningkatkan latensi eksekusi ke tingkat multi-detik.
• Biaya Eksponensial: Skalabilitas langsung terikat dengan volume request. 10.000 concurrent user yang menjalankan simulasi masing-masing akan memicu konsumsi vCPU masif secara bersamaan.

3. Matriks Perbandingan & Analisis Biaya

Berikut evaluasi teknis antara Batch vs Real-Time untuk turnamen dengan 64 peserta dan 100.000 iterasi per bracket saat traffic peak:

4. Implementasi Worker Batch Paralel (Go)

Untuk komputasi batch yang efisien, hindari alokasi memory di dalam hot-loop dan distribusikan iterasi Monte Carlo ke seluruh core CPU yang tersedia menggunakan worker pool berbasis Goroutine.

package main

import (
	"fmt"
	"math/rand"
	"runtime"
	"sync"
	"time"
)

type SimulationResult struct {
	TeamAWins int
	TeamBWins int
}

func worker(iterations int, winProbTeamA float64, out chan<- SimulationResult, wg *sync.WaitGroup) {
	defer wg.Done()
	// Gunakan RNG lokal per goroutine untuk mencegah lock contention pada global rand source
	r := rand.New(rand.NewSource(time.Now().UnixNano()))
	res := SimulationResult{}

	for i := 0; i < iterations; i++ {
		if r.Float64() < winProbTeamA {
			res.TeamAWins++
		} else {
			res.TeamBWins++
		}
	}
	out <- res
}

func RunBatchSimulation(totalSimulations int, winProbability float64) SimulationResult {
	numWorkers := runtime.NumCPU()
	simsPerWorker := totalSimulations / numWorkers
	out := make(chan SimulationResult, numWorkers)
	var wg sync.WaitGroup

	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go worker(simsPerWorker, winProbability, out, &wg)
	}

	wg.Wait()
	close(out)

	aggregated := SimulationResult{}
	for r := range out {
		aggregated.TeamAWins += r.TeamAWins
		aggregated.TeamBWins += r.TeamBWins
	}

	return aggregated
}

func main() {
	simulations := 1_000_000
	probTeamA := 0.58 // 58% peluang kemenangan berdasarkan pemodelan ELO

	start := time.Now()
	res := RunBatchSimulation(simulations, probTeamA)
	duration := time.Since(start)

	fmt.Printf("Total Sims: %d in %v\n", simulations, duration)
	fmt.Printf("Team A: %.2f%% | Team B: %.2f%%\n",
		float64(res.TeamAWins)/float64(simulations)*100,
		float64(res.TeamBWins)/float64(simulations)*100)
}

5. Pola Hibrida: Solusi Praktis Produksi

Pendekatan paling scalable untuk sistem simulasi skala produksi adalah model arsitektur Hybrid Two-Tier:

• Tier 1 (Public Baseline): Menggunakan batch pipeline dengan 100.000 iterasi. Dihitung setiap jam atau pasca-pertandingan, disimpan sebagai aset statis di CDN. Bagian ini melayani 95% traffic pengunjung umum tanpa menyentuh server komputasi.
• Tier 2 (What-If Custom Sandbox): Menggunakan worker on-demand, namun jumlah iterasi diturunkan menjadi 5.000–10.000 iterasi untuk membatasi eksekusi di bawah 250ms. Akses dilindungi dengan rate-limiting ketat per user token untuk mencegah exhaustion pada CPU pool.

Pola ini menjaga tagihan infrastruktur tetap terkontrol sembari tetap memberikan fleksibilitas komputasi dinamis bagi fitur analitik tingkat lanjut.