GH GambleHub

Gamble Hub Platform Architecture

1) Goals and principles

Purpose: Peak-resistant, compliant and cost-effective iGaming platform with fast Time-to-Market.

Principles:
  • Domain-Driven Design: clear bounded contexts and contracts.
  • Event Core (EDA): Events are the source of truth about change.
  • Idempotency and observability: all critical flows with idempotence keys and tracing.
  • Default security: Zero Trust, least privileges, encryption.
  • Scaling and fault tolerance: multi-AZ/region, degradation modes.
  • FinOps: $/1000 RPS, $/ms p95, CDN/cache-oriented.

2) High level diagram (logical)


[Users/Affiliates/Partners]
│
┌────────────┐
│ Edge (CDN, │ Anycast, WAF, bot filters, SSL/TLS, rate-limit
│ WAF, PoP) │
└─────┬──────┘
│
┌───────────────┐   mTLS/JWT, throttling, canary
│ API Gateway / │──────────────────────────────┐
│ Reverse Proxy│                 │Backoffice/Operator UI
└───┬─────┬─────┘                 │(RBAC, audit)
│   │                    │
│   └────────→ Admin/API (RBAC, IAM) ─────┘
│
Payment ├──Orkestr (PSP Router, KYC/AML, RG)
├──Igrovoy domain (Aggregator, Sessions, RNG proxy)
├──Finansovyy domain (Wallet, Ledger, Limits)
├──Produktovyye domains (Bonus/Promo, Tournament, Loyalty)
├──Polzovatelsky domain (Account, Auth, Profile)
├──Komm. domain (CRM, Push/Email/SMS, Segments)
└──Risk/Antifrod (Rules, Scoring, Device/Intel ASN)
│
┌──────────┴──────────┐
│ Event Bus (Kafka) │ topics: payments, bets, wins, sessions, kyc, promo, audit
└───────┬─────────────┘
│
┌───────────┴───────────┐
│ Data Platform (RT +  │ Stream proc, OLAP DWH, Lake, feature store, BI
│ Batch: DWH/Lake/RT)  │
└────────────────────────┘

3) Domain outlines and key services

3. 1 User and access

Account/Auth: registration, login, MFA, sessions, locks.
Profile/Preferences: locale, limits of responsible play (RG).
IAM/RBAC: operators, support, roles and audits.

3. 2 Finance

Wallet/Ledger: multi-currency wallets, transactions, fund locks, journal in immutable stor.
Payment Orchestrator: PSP routing, idempotency, priorities, failover, Time-to-Wallet metrics.
Limits & Compliance: limits of deposits/rates/losses, sanctions and country compliance.

3. 3 Content and gameplay

Game Aggregator: provider catalog, session launch, status broadcast, web hooks.
RNG/Proxy: safe routing to RNG providers, integrity control.
Session & Bet Engine: bets, results, calculation of winnings, anti-doubles.

3. 4 Promo and Hold

Bonus Engine: deposit/non-deposit, fripins, wagering, expiry.
Tournament/Leaderboard: real-time updates, anti-abuse.
Loyalty/Progression: levels, XP, missions, showcase offers.

3. 5 Risk and antifraud

Rule Engine: deterministic rules, scoring, velocity-checks.
Device/Network Intelligence: fingerprint, ASN/geo-behavioral cues.
Case Management: investigation, SAR/strikes, escalations.

3. 6 KYC/AML & RG

KYC: document verification, third party sources

AML: lists, transaction monitoring, reporting thresholds.
Responsible Gaming: limits/self-exclusions/timeouts with event notification.

3. 7 Communications and CRM

Segments/Eligibility: audience, frequency, risk rate.
Journey/Orchestrator: каналы email/SMS/push/in-app.
Content: banners, promo pages, A/B feature flags.

4) Integration layers

API Gateway / Reverse Proxy

TLS 1. 3, mTLS for partners, JWT/OIDC, HMAC signatures (external sausages).
Routing: host/path/header, canary/weighted, geo-routing for PoP.
Protection: WAF, bot filters, rate-limit, request-collapsing, half-speaker cache.

Event Bus (Kafka)

Топики: `payments.`, `wallet.`, `betting.`, `rg.`, `kyc.`, `promo.`, `audit.`.
Warranties: "at least once," idempotence keys, deduplication, DLQ.
Schemes: Avro/Protobuf + registry, evolution of schemes.

Payment Providers (PSPs)

Smart-routing by methods/countries/ASNs, provider limits.
Web hooks with signature verification, repeated delivery, anti-duplicate.
Reconciliation: reconciliation of diaries, discrepancies and alerts.

Content Providers

IP safe list, tokens/signatures, timeouts/retrays with budget, SLA provider.
Meta-catalog and health-checks, gray routes for suspicious sources.

5) Data and analytics

RT contour

Stream aggregations (win/loss, GGR/Net Deposits, activity), anti-fraud signals.
Feeds for storefronts, leadboards, CRM triggers in seconds.

Batch/DWH/Lake

Layer model (Bronze/Silver/Gold), SCD, GDPR deletions, data contracts.
BI/financial reporting: Net Deposits, Time-to-Wallet, ARPPU/LTV, cohorts.
Feature Store for ML (scoring risk/outflow/personalization).

6) Observability and SRE

Метрики: p50/95/99, error-rate, throughput, saturation, queue-lag, Time-to-Wallet, hit-ratio CDN.
Logs: structural, PII filtering, sampling.
Trails: end-to-end (traceparent), tail-based sampling on tails.

SLO (examples):
  • API p95 ≤ 250 ms; error ≤ 0. 3 %/30 days.
  • Payment "deposit" p95 ≤ 6 s; success ≥ 97%.
  • Bonus issuance ≤ 500 ms p95.
  • Alerts: the error budget has been violated, the growth of 429/retrays, the lag of event consumers, the decline in TLS resumption.

7) Safety and compliance

Zero Trust: mTLS east-west, least privilege policy, explicit network boundaries.
IAM: centralized token checking, short-lived credits, secret manager.
WAF/DDoS: signatures + behavior, greypass/captcha, tiered-cache/negative-cache.
Encryption: in transit (TLS) and "at rest" (KMS, DB columns).
GDPR/PII: minimization, pseudonymization, right to be forgotten, access audit.
KYC/AML/RG: mandatory inspections and reporting; case management.
Audit trail: unchangeable log for operators, critical events and configs.

8) Reliability, DR and topologies

Multi-AZ/Region: asset-asset front, asset-liability of critical storages according to RPO/RTO.
PoP/Edge: closer to the player, Anycast, origin-shield, warm-up caches.
Failover playbooks: loss of region, degradation of provider, partial cache down.
Degradation modes: simplified showcase/catalog, cache responses, deferred CRM features, light anti-fraud.

9) Performance and economy

CDN/TTL: SWR/if-error, noise-free cache key, tiered/shield.
HTTP/3, TLS resumption: reducing handshakes ChaCha20 on mobile.
gRPC/protobaph: inter-service calls.
Caches: Redis for hot-set (catalogs, profiles, limits).
FinOps: mix reserved/on-demand/spot, auto-parking stages, sampling logs/trails.

10) CI/CD and developer platform

IaC: Terraform/Helm, OPA policies (tags, TTL, classes).
Pipelines: linters/tests/sexcans/perf-smoke; release train, canary/blue-green.

Secrets: vault/secret-manager, rotation, no "secrets in the gith."

Feature flags: progressive rollout, A/B, disabling "hot" features instantly.
Golden Paths: service templates (metric/log/trace wrappers, retrai, idempotency).

11) Data and event contracts (example)

Event'wallet. transaction. v1` (protobuf):
  • `tx_id` (uuid), `idempotency_key`, `subject_id` (user), `amount` (minor units), `currency`,
`type` (depositbetwinwithdrawal), `status`, `created_at`, `meta` (psp_id, game_id).
Requirements: invariability of the event, strict evolution of schemes (backward-compatible), SLA delivery ≥ 99. 9% in 5 min.

12) Mini playbooks

Before peak event (T-30 min)

1. Increase minReplicas and minNodes of target services, warm pools.
2. Warm up CDN/DNS/TLS/connections, warm up popular directories/tournaments.
3. Tighten bot-rules and include gray routes.
4. Check PSP limits, health content providers.

Payment incident (increase in PSP-1 failures)

1. Convert weight to PSP-2/3 (smart-routing), increase retry-budget with backoff.
2. Enable status banner and alerts.
3. Post-incident: RCA, redistribution of provider portfolio.

Database degradation (growth of p95 requests)

1. Turn on the caching layer, lower the frequency of heavy windows.
2. Temporary limits on tokens/bonuses, queues for settlement.
3. Optimization plan: indexes, partitions, read-replicas.

13) SLO set (example)

API: p95 ≤ 250ms, error ≤ 0. 3% (30 days).
Payments: T2W (deposit) p95 ≤ 6 s; 'success _ rate' ≥ 97%.
Gaming sessions: creation ≤ 300 ms p95, connection stability ≥ 99. 9%.
Antifraud: solution time ≤ 200 ms p95 for online rules.
DWH: SLA readiness daily storefronts - 06:00 local TZ.

14) Evolution Roadmap

1. v1: core monolith + gateway, Kafka "inside" (minimal topics), basic analytics.
2. v2: domain allocation (wallet, payments, bonus, aggregator), full events, Redis, CDN policy.
3. v3: multi-region asset-asset front, asset-liability storage, smart-routing PSP, RT-leaders.
4. v4: ML scoring (feature store), personalization of offers, automatic FinOps optimizer (commit/spot mix), Zero Trust end-to-end.

15) Production readiness checklist

  • Domain boundaries and contracts (API + events) are documented.
  • Payment/bid identity and overall dedupe are implemented.
  • SLO/alerts by key flows (API, Payment, Wallet, Bonus, Tournament).
  • WAF/DDoS/bot filters and rate-limits enabled, auditing enabled.
  • DR plan and exercises (loss of AZ/region, content provider/PSP).
  • Observability: metrics/logs/traces, dashboards of peak events.
  • CI/CD with canary/blue-green and fast rollback.
  • FinOps: tags, showback/chargeback, $/1k RPS, lifecycle/sampling.
  • GDPR/KYC/AML/RG processes with audit and SLA.
  • Security reviews: secrets, IAM, access policies, encryption.

Total

The Gamble Hub architecture is a collection of independent event-related domains with strong security, observability, and cost-effectiveness. This design provides predictable performance for tournaments and broadcasts, fast integrations with providers, controlled payment flows and transparent financial indicators - while remaining compliant and ready to scale across regions.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Telegram
@Gamble_GC
Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.