Load testing: player profiles and traffic peaks

1) Why model profiles rather than "average temperature"

iGaming loads have high explosives: promos/tournaments/streams give multiple bursts of RPS, and the distribution of actions is uneven (login→depozit→stavki/vyvod). The test must reflect the behavior of the segments (beginners, VIP, "bonus hunters," mobile), otherwise you will get "green graphs" and red incidents.

Key SLOs (30-day example):

Login: success ≥ 99. 9%, p95 ≤ 250 ms
Deposit: success ≥ 99. 85%, p95 ≤ 400 ms
WS: p95 message RTT ≤ 120ms, disconnect rate ≤ 0. 5%
Game launch: success ≥ 99. 8%, p95 ≤ 800 ms

2) Player profiles (behavioral scenarios)

A. Newbie (new player) - 25-40% peak traffic

Path: registration → login → view promo → deposit (small amounts) → launch of 1-2 slots

Features: high proportion of UX errors, retray payments, jumps between pages

B. Regular - 40-50%

Path: login → quick deposit/no deposit → 3-5 games → rare withdrawal

Features: stable sessions, sensitive to p95> 200ms on WS

C. Bonus-hunter (promo) - 10-20% at promotions

Path: Register → Activate Bonus → Minimum Bids → Quick Withdrawal Attempt

Features: outbursts to '/promo/claim ', retray abuse, frequent 429 without correct limits

D. High-roller/VIP - ≤ 1%, but high check

Path: login → large deposit → live games/high stakes → withdrawal

Features: sensitive to any delay/files of the game provider, critical SLA payments

E. Bettor (sports/live)

Path: login → subscription to quotes → frequent bets in "narrow windows" (up to 10-30 s)
Features: pulsating WS load/coefficient cache, goal bursts/VAR

3) Traffic models and timing

Open vs Closed model

Open (Poisson, arrivals/sec) - suitable for public promos and streams (users "come themselves").

Closed (fix. number of virtual users with think-time) - for stable sessions (VIP, live games).

Traffic patterns:

Ramp: linear acceleration x1 → x5 in 10-20 minutes
Burst: x3-x10 "bang" for 30-120s (bonus/jackpot/goal announcement)
Wave: Ridges every 5-10 min (stream/tournament rounds)
Soak: 2-12 h stable load (leaks, GC, descriptors, degradation)

4) Critical flow and metrics

Authentication and Profile

RPS on '/login ', '/2fa/verify', p95/p99, error-rate, lock/ratelimit-trips

Payments

`/payments/deposit	withdraw 'by providers: success-ratio, p95/p99, sausages, idempotence
PSP limits (per-merchant RPS/transactions per minute), retray queue

Gaming gates

Starting a slot/live table: success-ratio, time-to-first-spin, provider failure

WebSocket: connections in peak, messages/sec, RTT, rate-limit/429, reconnects/min

Promos/Bonuses

'/promo/claim ', '/freespin/activate': 200/4xx/5xx, share 409/competitive updates, cascades to wallet

Vaults and queues

Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses

5) Geo and Reality Network

Geographic distribution by market (EU/LatAm/MEA/APAC) and ASN mix (mobile networks, hosting).

edge→origin latency (Anycast/CDN), mobile RTT, packet loss.

A/B: with CDN and bypassing (origin) - to evaluate the "clean" backend.

6) Test data design

Pseudonymized accounts, BIN cards by region, currencies, KYC states.

Realistic behavioral timings: think-time 1-7 s for casual, 0. 3–1. 2 s for live bets.

Control of non-idempotent operations (withdrawal/deposit): dry mode for PSP sandbox, wallet plugs.

Anti-fraud/bot filters: whitelist of test ASN/IP/devices, otherwise WAF/anti-bot will "strangle" the stand.

7) Test plan (template for release/promo)

1. Smoke load: 10-20% of peak, 30 min

2. Capacity ramp: x1 → target → x1. 5 from target peak, 10-15 min per step

3. Burst-series: 3-5 waves of 60-120 s on x3-x5 from current level

4. Soak: 4-8 h at 60-80% peak (leakage, degradation)

5. Failover/Chaos: disabling one PSP/PoP, degrading the game provider, dropping one shard database

6. WS-storm: mass reconnect + 5-10 × messages within 2-3 min

7. Promo-storm : /promo/claim + registration + deposit in 60-sec "window"

Exit criteria: all SLOs in the green zone; headroom ≥ 30% over CPU/connections; PSP quotas are not exceeded; no queue growth and p99 after the test.

8) Infrastructure patterns to withstand peaks

Warm-pool/provisioned concurrency (functions/containers), pre-scale before promo.

Connection pooling and upstream limits (DB/PSP) + request queues.

Idempotency keys on deposits/webhooks.

Backpressure: 429/503 with 'Retry-After', degradation of "heavy" roots (reports/search).

Cache/edge cache of coefficients and static metadata of games.

9) Anti-regression: what "breaks" in the first place

Overflowing DB pools → p99 growth and timeouts

Wallet-locking for mass balance updates

PSP-rate limits → avalanche of retrays and takes
WS-broadcast for thousands of non-butchered subscriptions
Too aggressive WAF rules → FPR on login/deposit

10) Observability during the test

Dashboards RED/USE + business funnels (login→depozit→stavka→vyvod).

End-to-end traces for slow/error queries (100% sample errors).

Test stage markers (ramp/burst) in metrics/logs.

Separate PSP/game provider panels, retray queue, idempotency hits.

11) Team and Process

War-room: performance engineer, backend, SRE, risk/payments, WAF/security, product.

Runbook: what we do with p99> target, how we reduce the load, who to call from the provider.

Report: SLO, bandwidth, bottlenecks, cost, code/architecture/quota recommendations.

12) Kapasiti plan: from number of players to RPS

Evaluation (example):

Concurrent players at peak: 50k
Average frequency of actions: 0. 25–0. 5 req/s per player (mobile below, live above)
RPS Evaluation API: 12. 5k-25k + service requests (wallet, providers, cache)
WS: 30-60k active connections, 3-8 msg/s per table/theme
Add 30-50% headroom to burst and retrai

13) Bench preparation checklist

Data: accounts/wallets/cards/currencies/countries/games, pseudonymized
Isolation of payments: sandbox + plugs of webhooks, prohibition of "live" write-offs
Edge/CDN/WAF as in prod; anti-bots in "soft" mode for test ASN
Observability: dashboards, alerts, tracing enabled
Autoscale and warm-pool configured; pool/connection limits documented
Canary flag for "heavy" features (reports, mass exports)

14) Tools (landmarks)

Generators: k6, Gatling, Locust (HTTP/WS), JMeter (including WebSocket plugin)

Feed emulators: custom scripts of quotes/game providers

Replay traffic: tcpreplay/ingress mirroring with anonymization and normalization

15) Example of the profile "Promo tournament, 60 seconds before the start" (case)

Wave − 5 min → 0:

Open arrivals: 400 → 2,500 req/s (login/refresh)
'/promo/claim ': bursts of 1,000 rps 3 × of 20 s
WS: + 15k connect, + 5 msg/s on "leaderboard"

Readiness:

Cache pre-warm and warm-pool
Rate-limit '/promo/claim ': 10/min IP, 2/min account, 30-second negative answer cache
Idempotence and bonus accrual queue (batch 50-100/cycle)
"Soft" 429 with 'Retry-After' + UI progress

Success criteria: no degradation of login/deposit SLO, p95 WS <150 ms, <0. 5% claim errors, no queue inflation.

Resume Summary

iGaming load testing is behavioral modeling, not "endpoint shooting." First, define SLOs and player profiles, then select the traffic model (open/closed), build real login/deposit/betting/promo scenarios with geo and PSP limits, test bursts and soak, enable observability and prepare autoscale. Fix the result with a capital plan and runbooks - this way you will meet traffic peaks without surprises and conversion losses.