Charding e replica dei database

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Per le piattaforme iGaming, aumento del traffico (scommesse, depositi, siti PSP, eventi di gioco) e requisiti di disponibilità (≈99. 9–99. 99%) si riversano rapidamente nel limite di un database. La replica consente la scalabilità orizzontale della lettura e la disponibilità di errore. sharding - ridimensionamento orizzontale della scrittura e dei dati. La chiave sono compromessi PACELC consapevoli (dopo aver rifiutato: CA/P, altrimenti Latency vs Consistency), SLO chiari e disciplina schemi/chiavi.

Termini e modelli

Replica - Copia dei dati tra i nodi.

Leader-Follower (Primary-Replica) - Una sola voce consente di leggere molte letture.
Multi-Leader (Active-Active) - Registrazioni in più regioni, conflitti/merge.
Consensus-replication (Raft/Paxos, NewSQL): registrazioni quorum (Cassandra/Scylla - quorum AP, CockroachDB/Yugabyte - quorum CAP).
Sync/Semi-sync/Async - Saldo ritardo vs RPO.
Lo sharding è una ripartizione orizzontale di tabelle/chiavi per chard.

Hash-sharding (uniformità, intervalli più complessi).
Range-sharding (intervalli di chiavi, rischio di calore).
Consistent hasing (morbida aggiunta/decadenza di nodi).
Geo-sharding (per regione/giurisdizione).
Sharding funzionale (per dominio: pagamenti/rate/CRM).

Quando e cosa scegliere nel iGaming

Solo replica (senza sharding): quando il problema principale è la lettura: nastri, report, cataloghi pubblici. I record vengono inseriti nello stesso comando, le letture nelle repliche.
Sharding - Quando la voce/memorizzazione è ristretta, flusso di scommesse, transazioni di bilanci, eventi di trigger.

• La latitudine ai giocatori/PSP consente di leggere le repliche in locale.
• Regolazione (localizzazione dei dati): geo-sharding.
• DR interregionale con replica asincrona + piano di cambio.

PACELC e proprietà di garanzia

CAP - Seleziona C (consistenza) o A (disponibilità) in una rete split.
PACELC - In assenza di errori, selezioniamo tra Latency (L) e Consistency (C).
Percorsi di cassa (bilanci, prelievi): solitamente C/stretch serializable o Serializable + idampotenza aziendale.
I sottosistemi meno critici (login click, directory) sono orientati a L (AP/CE, eventual).

Replicazione: pratiche

Leader–Follower

Record leader, letture di repliche (read scaling).
Read-after-write - Per le operazioni personalizzate, leggere dal leader o attendere la lega (verifica «last _ committed _ lsn »/« wait _ for _ replay _ lag»).
Semi-sync su percorsi critici (riduzione RPO a costo di latenza).
Failover: automatico (patroni/raft coordinatore) + fencing (per non avere un doppio leader).

Multi-Leader

È utile per domini separati e un basso conflitto (ad esempio, contenuti/impostazioni), ma non per un unico conto giocatore senza misure speciali.
Criteri di merge: last-write-wins, CRDT, regole di dominio per il consolidamento.

Consensus/Database quorum

Scrittura con quorum (ad esempio, WRITE QUORUM), lettura con quorum (READ QUORUM) → una consistenza forte/personalizzabile.
Tenere conto della latitanza MJ/AZ/regioni e del costo del quorum.

Scharding strategie e scelta della chiave

Come selezionare una chiave

Distribuzione stabile per player _ id/account _ id/bet _ id.
Evitare le chiavi monouso (auto-increment) nel range-charding - coda «calda».
Per i pagamenti - spesso «player _ id» o «account _ id»; per i loghi: 'event _ timè + bucketing; per i contenuti, 'tenant _ id'.

Strategie

Hash-sharding player _ id - Bilancia del flusso di scommesse/bilanci.
Range-sharding in base al tempo per gli analisti/archivi.
Geo-Sharding: I giocatori UE sono in linea con le leggi locali.
Ibrido: hash all'interno della regione + geo giurisdizione.

Lotta contro le chiavi hot

Key-salting (aggiungere sale/bucket alla chiave).
Write-throttling per entità, coda command (serial executor).
Materializza «aggregati» (bilanci) in uno store separato con una coda di sequenza.

Operazioni cross-shard

Bonifico/rimborso: evitare 2PC sulle vie calde.
Saga-pattern: suddivisa in transazioni locali + azioni di compensazione, idemoticità rigida e outbox.
2RS/protocolli commit - Ammissibili (batch back-office), ma costosi per latitanza e tolleranza.
Proiezioni - Visualizzazioni di lettura (read models) per schermate tra domini, aggiornate dallo striping.

Schemi, indici e evoluzione

Versioning dello schema - Migrazione da back-compat, feature-flags sul codice.
Indici per chiavi di scardinamento e frequenti richieste; evitare cross-shard join (fare pre-join/denormalizzazione).
Per JSON/Doc Storage - convalida i circuiti (JSON-Schema/Protobuf) e TTL per le collezioni «rumorose».

Ridimensionamento online e resharding

Pianificare un numero di virtuali (slots) flessibile.
Consistent hasing o nodi virtuali per l'aggiunta di nodi morbidi.

• doppia voce (vecchio + nuovo shard), validazione della consistenza;
• Copie di sfondo delle chat (logical dump/table move/streaming clone)
• passa a «marcatore» + finestra di osservazione, quindi rimuove il doppio record.
• Cambiare ruolo, drenare i connettori.

SLO, osservabilità e alerting

SLO scrittura/lettura: p99 X ms su tabelle hot, repliche Y validi secondi, disponibilità Z.
Metriche: TPS, p95/p99, replication lag, conflittualità (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, iOPS/latency disk.
Traccia: «trace _ id» nelle richieste di database, associare al broker/bus eventi.
Richieste canarie e synthetic transations per il primo oggetto di degrado.

Sicurezza e conformità

Crittografia a riposo e transito (TLS), rotazione delle chiavi.
RBAC/ACL, segmentazione per domini/tenenti, cluster singoli per pagamenti/CUS.
Localizzazione dati (EU/TR/LATAM) - Combina geo-sharding e regole di retrazione.
Verifica di chi e cosa ha letto/regole; maschera PII esportazione del controllo.

Bacap, PITR, DR

Backup completi + incrementali, deposito off-line.
PITR (point-in-time recovery) per i cluster leader.

• Domini critici (saldo/pagamento) - -30s (semi-sync o frequente WAL-shipping), RTO minuti con failover automatico.
• Meno critici sono RPO fino a minuti/ore.
• Esercitazioni DR (game day) e runbook documentato di commutazione.

Prestazioni e sintonizzazioni (brevemente)

Memoria/cache: ingrandisci i buffer (shared buffers/innodb buffer pool), tieni d'occhio la cache-hit al 95%.
Cronologia/motore: NVMe veloce, volume separato sotto WAL/redo.
Pool di connessioni (PgBouncer/Hikari).
Pianificatore/statistico: analisi automatica/autoscatto (Postges), compattazione/tuning GC (motori LSM).
Quorum/replica-fattore - Bilanciamento tra p99 e failover.

Topologie tipiche per i iGaming

1) Bilanci e pagamenti (circuito COP)

Leader-Follower nella regione del giocatore, semi-sync alla replica ravvicinata.
Hash-sharding su «account _ id».
Leggere «dopo la scrittura» dal leader; proiezioni in Redis per API-latency.
Outbox un di eventi per calcoli/analisi.

2) Cronologia delle scommesse/eventi di gioco (login orientato AP)

Range-sharding in base al tempo o hash in «player _ id» in un invertebrato/archivio LSM.
Repliche asincrone per report/OLAP.
Avvenual consistency è accettabile, più importante è la larghezza di banda.

3) Profili/CRM (Multi-region read, localizzazione)

Geo-sharding giurisdizione, repliche locali per la lettura.
Registrazioni tramite il leader più vicino; regione crociata - asincrona + risoluzione dei conflitti solo per campi non critici.

Esempi (concettuali)

Postges - Charding dichiarativo per «player _ id»

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Scrittura quorum (pseudo)

WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Saga invece di 2PC (semplificato)

1. Azzera deposito per shard-A (idempotent).
2. Invia l'evento «ritirato» al servizio di pagamento shard-B.
3. Se il passaggio 2 è incompleto, compensare il passaggio 1 con l'evento «ritorno».

Assegno foglio di implementazione

1. Definire i domini dati e SLO (p99, RPO/RTO, repliche).
2. Selezionare un modello di replica (leader/follower, quorum) e una strategia di sharding.
3. Fissa le chiavi di sharding e schema (invariabili!).
4. Immettere il criterio read-after-write e l'instradamento delle letture.
5. Progettare il resharding online (dischi virtuali, record doppio).
6. Assicurati idemoticità e outbox per eventi/comandi.
7. Personalizzare backap, PITR, DR e esercizi regolari.
8. Attivate l'osservazione, i quorum, le chiavi calde, i conflitti.
9. Documentazione runbook: failover, split-brain, degrado.
10. Eseguire test di carico/caos per i picchi materici.

Antipattern

Uno shard gigante dì tutto "e" poi tagliamo ".
Join's cross-shard'sul percorso caldo della richiesta.
Nessun criterio read-after-write.
Migrazioni di schemi che rompono le chiavi di sharding.
Multi-leader per i conti in denaro senza una risoluzione rigorosa dei conflitti.
Nessun PITR/DR - Impossibile recuperare da un errore logico.

Riepilogo

La replica risolve la lettura e la disponibilità, lo sharding e il volume. L'architettura di successo nel iGaming è un chiaro SLO e compromesso PACELC, chiavi di sharding stabili, un minimo di coordinazione cross-chard (saga al posto di 2PC), disciplina read-after-write, Read-after-resharding online regolari e esercitazioni DR regolari. Questo approccio è scalabile sotto i picchi dei tornei, supporta i limiti regolatori di localizzazione dei dati e rimane prevedibile in uso.