Architettura a microservizi

1) Perché i microservizi nel iGaming

Velocità di modifica: rilasci indipendenti dei team (pagamenti, contenuti, rischi, tornei).
Affidabilità: l'interruzione di un servizio non cancella l'intero prodotto (limiti di guasto).
Scala: lo scale orizzontale dei domini hot (portafoglio, lobby, striam).
Segregazione dei dati per regione/giurisdizione.

Quando non è il caso, un piccolo comando/volume, nessuna pratica DevOps, una scarsa automazione dei test - allora il monolite modulare è migliore.

2) Domini, bordi e comandi (DDD + Team Topologies)

Tracciati di dominio: Account/Profilo, CUS/Complaens, Pagamenti/Portafoglio, Contenuti di gioco/aggregazione, Bonus/Missioni, Tornei, Marketing/CRM, Report/BI.
Bounded Text = Contratto del modello di dati e del linguaggio.
Flusso di modifica del comando: un comando = un tracciato + il proprio SLO.
BFF (Backend for Frontend) - Sfaccettature separate sotto il Web/Mobile/Partner per non raccogliere «orchestrazione» sul cliente.

3) Comunicazioni: sincrono vs asincrone

Sincron (REST/gRPC) - Quando si desidera una risposta immediata (controllo dei limiti di deposito).
Asinhron (Kafka/NATS/SQS) - Eventi e processi di sfondo (accantonamento della cache, distribuzione, aggiornamento degli ascolti).

• Percorso critico = minimo hop di rete.
• Integrazione tra domini - attraverso eventi e API contrattuali.
• Non costruire «catene da 5 chiamate sincronizzate» in linea per utilizzare EDA/Sags.

4) Contratti e versioning

Contratto 1: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + compatibilità: l'aggiunta di campi non compromette i clienti.
Consumer-driven contracts (CDC) - Automezzi in CI (contro le regressioni).
Deprecation policy: finestra di supporto (12-18 mes), telemetria secondo le versioni precedenti.

5) Eventi, saghe e consistenza

Outbox/Communication Log Tailing - Registrazione atomica dati + evento.

• Orchestrazione (coordinatore centrale) per i pagamenti/conclusioni.
• Coreografia (reazione agli eventi) per bonus/missioni.
• Idempotenza: chiavi su «entityId + action + nonce», memorizzazione del Registro di sistema.
• Consistenza: «esterno» attraverso gli eventi; «interno» - transazioni all'interno del servizio.

6) Dati e storage

Ogni servizio possiede il proprio database (isolamento dei circuiti).

• Transazioni/bilanci - relazionali (PostgreSQL) con invarianti rigorosi.
• Eventi/loga - append-only (Kafka/Redpanda).
• Kesh/sessioni - Redis/KeyDB; I liderboard sono i Redis Sorted Set.
• La ricerca è OpenSearch/Elastic.
• Proiezioni materializzate in lettura (CQRS) - Elenchi/report rapidi.

7) Affidabilità e sostenibilità

Timeouts/Retry with jitter/Retry-budget solo per le operazioni idropotenti.
Circuito-breaker/Outlier-ejection tra i servizi.
Bullkhead - pool singoli per gli upstream «rumorosi».
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-messaggistica handling in coda.

8) Osservabilità (Osservability)

Traccia: OpenTelemetry («trace _ id» attraverso il shlyuz→servisy→BD).
Metriche: RPS, p50/p95/p99, errato rate 4xx/5xx, saturation (CPU/mem/queue), metriche aziendali (TTP, TtW).
Loghi: JSON strutturale, occultamento PII/PAN/BAN, core'trace _ id '.
SLO/alert (ad esempio, "Deposit p95" 300 ms "," success "98. 5%`).

9) Sicurezza e compliance

Zero-Trust: (SPIFFE/SPIRE), certificati a breve vita.
AuthN/Z: OAuth2/JWT (aud/scope/exp), separazione attributaria dei ruoli.
Segreti: KMS/Secret Manager/Sealed Secret, rotazione delle chiavi.
GDPR/Localizzazione dati: cluster regionali, geo-fencing sul gateway API.
Controllo: registri invariati (WORM), tracciamento delle azioni admine.

10) Distribuzione e rilascio

Contenitori/K8s: un servizio = uno deploy; risorse/limiti PodDisruptionBudget.
CI/CD: lenti, unit/contract/test integ, sicurezza scan, SBOM.
Release: canary/blue-green/shadow, migrazione di diagrammi attraverso expand-and-contract.
Scale automatico: HPA CPU + RPS + p95 + queue-depth; drain al taglio.

11) Prestazioni e costi

Profilazione: p95/99 per servizi e metodi, flame.
Cache: read-through/write-through; TTL/invalidità per eventi.
Data locality - Mantenere i dati caldi vicini al calcolo.
FinOps: target di caricamento 60-70%, «warm pools», interruzione automatica dei worker inattivi.

12) Modelli di dominio (iGaming)

12. 1 Pagamenti/Portafoglio

Servizi: 'payments-gw' (facciata), 'wallet', 'psp-adattaters',' fraud-check '.
Flusso: 'init-reserve-capture/rollback' (saga).
События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idampotenza: «Idempotency-Key», deadup in «wallet».

12. 2 CUS/Complaens

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Controllo e ETA: coda di attività, valigetta in linea, post-azioni.

12. 3 Bonus/Missioni

Servizi: bonus-engine, wallet-bonus, elisibility.
La coreografia è « ».
Protezione contro gli abusi: borse di studio idempotent, limiti, simulazione di regole.

12. 4 Tornei/Liderbord

Servizi: «Tornment-svc», «scoring», «leader».
Storage: Redis ZSET + Scollatura periodica in OLAP.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Esempio di contratto + evento (semplificato)

OpenAPI (frammento) - Wallet

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (sezione) - evento

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) Test

Unità/Property-based per le regole di dominio.
CDC (Pact/Assertible) è un contratto-test dei provider/consumatori.
Integrazione con broker locali (Testcontainers).
Flow critici E2E ( ).
Test Chaos/Failover: disattivazione del PSP/caduta del broker/perdita della zona.

15) Metriche e SLO (minimo)

Disponibilità dei servizi: '≥99. 9% per i pagamenti/portafogli.
Latency p95: API del percorso critico di 300-500 ms.
Error budget: 0. 1–0. 5% a trimestre, burn-alerts.
Code: lead time evento ( ), DLQ 0. 1%.
Business: TTP, TtW, FTD-success, KYC-TtV.

16) Assegno fogli

Progettazione del servizio

• Bordo di dominio chiaro e proprietario dei dati.
• Contratti OpenAPI/AsyncAPI + schemi in Registry.
• SLO/alert definiti; metriche/roulotte/loghi sono incorporati.
• Politiche timeout/retrai/idipotenza.
• Migrazioni di diagrammi: expand-and-contract.

Prima del lancio

• Unità/CDC/test di integrazione verde.
• Percorso canario e piano di rientro.
• Rate-limits/percorsi di peso sono configurati.
• I segreti/chiavi/certificati vengono ruotati.
• Flag Fiech e Follback preparati.

17) Anti-pattern

Rete come bus dati: catene sincroni profonde anziché eventi.
«Dio» in comune è un database per tutti i servizi.
La mancanza di idampotenza è un doppio addebito/addebito.
Release scure senza telemetria e kill-switch.
Sessione nascosta (appiccicosa ovunque invece dello stato esterno).
Contratti in codice senza versione e CDC.
Logica nel gateway API invece dei servizi (gateway = sottile).

18) Migrazione monolite (Strangler Meg)

1. Seleziona la facciata gateway e il primo tracciato (ad esempio pagamenti).
2. Togli la logica binaria (outbox) dalla monolite agli eventi.
3. Trasferire gradualmente gli endpoint in un nuovo servizio (routing/pesi canarini).
4. Stringere il monolite fino a «kernel» e disattivarlo.

19) Stack e infrastruttura (esempio)

Comunicazioni: REST/gRPC, Kafka/NATS; Schema Registry.
PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
Contenitori/orchestrazione: Docker, Kubernets (Ingress/Gateway), Service Mesh (Istio/Linkerd), se necessario.
Gateway: Invoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Tacca finale

Progettare i limiti dei domini e della responsabilità dei dati.
Sincron è solo dove serve una risposta; Il resto sono eventi.
Contratti/schemi/CDC - assicurazione contro le regressioni.
Sags + outbox + idampotenza è il fondamento dell'affidabilità.
Osservabilità e SLO non sono un'opzione, ma un criterio «finito».
Release attraverso canary/blue-green, migrazioni - expand-and-contract.
Sicurezza/compilazione: mTLS, JWT, KMS, dati regionali.
Prima il monolite modulare, poi l'evoluzione - se la scala e la squadra sono pronti.