Come costruire fail-safe elaborazione di milioni di transazioni al giorno

Testo completo dell'articolo

💡 Materiale tecnico per i comandi di cibo e piattaforma fintech/giochi e settori adiacenti. Non una chiamata al gioco. Le transazioni comprendono le transazioni in denaro/conto (prelievo, iscrizione, trasferimento, settment, rimborso).

1) Cosa significa fail-safe per le transazioni

Fail-safe è quando qualsiasi situazione di fallimento porta a un arresto sicuro o a una condizione compensabile senza perdita di denaro e dati. Obiettivi:

«Doppi debiti/prestiti» = 0.
Transazioni/eventi perse = 0.
SLO prevedibile per latitanza/consegna, modalità di degrado nitide e DR.

La base sono gli invarianti in denaro (la verità del saldo in un unico luogo), l'idimpotenza, la consegna coerente degli eventi.

2) Principi architettonici (breve)

1. Single source of truth - Saldo e contabilità - in Ledger/Wallet. I servizi in giro mantengono lo stato dei processi, non i soldi.

2. Idempotency everywhere: tutte le operazioni di scrittura accettano Idempotency-Key; la ripetizione restituisce lo stesso risultato.

3. Eventi con garanzia di consegna: outbox/CDC, code, DLQ, deadup.

4. Saghe e compensi, non modifiche manuali.

5. Back-pressure e priorità: il sistema rallenta ma non crolla.

6. L'osservabilità predefinita è: loghi strutturati, tracking, metriche.

7. Multi-regione e DR: asset-asset/asset-passivo, esercitazioni regolari.

3) Topologia arbitrale


Edge/API GW ──Command API ──App Service (Sagas)
│           │
│         (Outbox TX)

RateLimit     Outbox Table ──Publisher ──Kafka/Pulsar ──Consumers
│                      │
WAF                     └─DLQ/Replay
│
└─Ledger/Wallet (ACID, idempotent debit/credit)
│
└─CDC/Changefeed ──DWH/BI/Recon

I luoghi chiave sono Outbox (scrittura atomica del comando e bozza dell'evento), Publisher (esatta consegna), Consumers (idompotenti, con chiave di deduzione), DLQ/Replay (ripetizioni controllate).

4) Invarianti in denaro e coerenza

La verità sul bilanciamento è Ledger (ACID, transazioni serializzate o rigida organizzazione in conto).

I comandi contanti: debit, credit, hold, commit, rollback sono idipotenti.

I processi combinati sono progettati come sagome:

"authorize" settle "(deposito/settlment)," sollest "submit" settled/failed "(pagamento/conclusione)," refund/void "(compensi).
Nessuna modifica diretta dei bilanci per superare Ledger.

5) Idempotenza: design delle chiavi

La chiave deve identificare in modo univoco l'operazione aziendale:

`bet_id+amount+currency`, `payment_intent+capture_id`, `payout_id`, `chain_txid`.
Memorizza il risultato in chiave (response cache). Ripetizione con la stessa chiave, identica a body/stato.
Controlla la non corrispondenza: la stessa chiave con l'altra somma dì IDEMPOTENCY _ MISMATCH '.

6) Code, ordine e deduzione

Gli effetti exactly-once non sono ottenuti dai trasporti, ma dai concimatori idropotenti + deadup (LRU/Redis/DB c TTL).

Mantieni l'ordine in base alla chiave (partition key = 'account _ id/round _ id/player _ id').

Per le chiavi eterogenee, versioning dello stato e switch (state machine per entity).

DLQ obbligatorio: dopo n tentativi, in un argomento isolato con causa umana.

7) Outbox/CDC: perché gli eventi non si perdono

Come parte di una transazione nel database del servizio, registriamo sia la modifica aziendale che la scrittura in outbox.

Un singolo publisher legge outbox e lo pubblica nel bus di conferma.

Alternativa: CDC (Change Data Capture) a livello di database (Debezium/Login di replica).

Non c'è nessun evento fuori dalla transazione, è la causa delle perdite.

8) Back-pressure e priorità

Token-bookets e quote di ingresso (per tenant/brand/region).

Le code con priorità sono le vie di denaro sopra la promo/telemetria.

In caso di sovraccarico: modalità «no new sessions/richiesti», congelamento dei fili secondari, salvataggio del nucleo.

Degrado automatico: ridurre la frequenza delle attività di sfondo, espandere dinamicamente i worker critici.

9) Sostenibilità multiregionale

Attivo per API e code, locale Ledger (o globale con sharding per regione/valuta).

Data residency: denaro/PII/riviste non vengono crittografate senza regole esplicite.

Replica degli eventi interregionale - asincrona, con «region».

RPO/RTO: baci RPO per 5 minuti, RTO per 30 minuti; Controlli regolarmente.

10) SLO/SLI e dashboard

Orientamenti (esempio):

p95 'authorize/debit/credit' <150-300 ms (percorso interno).
p95 end-to-end «komanda→sobytiye in un pneumatico» <1-2 s
Consegna di eventi web/esterni p99 <5 min
Transazioni perse/duplicate = 0 (controlli contrattuali).

Metriche: latency p50/p95/p99, error-rate (4xx/5xx/business), consumer/queue lag, retry storm, settle lag, webhook lag, dimensioni DLQ, frequenza'IDEMPOTENCY _ MISMATCH '.

11) Osservazione e verifica

Logi JSON strutturati con «trace _ id», «idempotency _ key», ID aziendale, codici di errore.

OpenTelemetry: tracking HTTP/gRPC/DB/pneumatici, span saghe.

Controllo WORM: registri di modifiche critiche invariati (limiti, chiavi, configi promo/jackpot).

Occultamento di PII/segreti, serbatoi regionali, RBAC/ABAC per l'accesso ai reparti.

12) Test di affidabilità

Test contrattuali: ripetizione/duplicati, out-of-order, idampotenza, deduplicazione.

Carichi: profilo picco (x10), stabilità code e database.

Le valigette del caos: la caduta di Ledger/portafoglio, il crollo delle code/regioni, i ritardi del CDC, la tempesta dei retrai.

Game Days - Esercitazioni regolari DR e incidenti, con misurazione MTTR.

13) Archivi e dati

OLTP per denaro: database transazionale (RPO≈0), indici rigorosi, livelli serializzati per entità critiche.

La cache è solo per accelerare, non per «verità». TTL + jitter, protezione da cache stampede.

OLAP/DWH - per report/analisi. Flussi da CDC/bus, senza carico OLTP.

Gli schemi di dati sono versionati; migrazioni senza downtime (expand/contract).

14) Orchestrazione dei retrai

Backoff esponenziale + jitter, deadline/timeout su RPC.

Ripetizione idropotente su ogni strato (il cliente il servizio di consumo).

Quote di retrai, proteggersi da «tempeste» (circuito breaker, hedged sollests se necessario).

Replay dal DLQ solo in finestre «sicure», con limitazione della velocità.

15) Sicurezza dei trasporti

mTLS dappertutto S2S, token a breve vita (OAuth2 CC), firme di corpi (HMAC/EdDSA) per webhoop.

Segreti in Vault/HSM, rotazione, chiavi per brand/region.

Regole least private, quattro occhi per operazioni manuali.

16) Contratti approssimativi (frammenti)

Comando Idempotent Debit


POST /v1/wallet/debit
Headers: X-Idempotency-Key: debit_pi_001, X-Trace-Id: tr_a1b2
{
"account_id":"acc_42",  "amount":{"minor_units":5000,"currency":"EUR"},  "reason":"payout",  "reference_id":"po_001"
}
→ 200 { "status":"committed", "entry_id":"e_77" }
(ripetizione della stessa risposta)

Evento outbox

json
{
"event_id":"uuid",  "event_type":"wallet. debit. committed",  "occurred_at":"2025-10-23T16:21:05Z",  "account_id":"acc_42",  "amount_minor":5000,  "currency":"EUR",  "reference_id":"po_001",  "idempotency_key":"debit_pi_001",  "schema_version":"1. 3. 0"
}

17) Assegno fogli

Piattaforma/operatore

La verità dell'equilibrio è un Ledger; Non ci sono vie di fuga.
Tutte le operazioni write con Idempotency-Key; memorizza la risposta sulla chiave.
Outbox/CDC per tutti i record di dominio, DLQ e replay gestito.
Code con priorità, back-pressure, modalità di degrado.
Partition-keys selezionati in base alle chiavi aziendali I consumatori sono idonei.
SLO-dashboard, , WORM.
Esercitazioni DR/xaoc regolari, test contrattuali/di carico.
Data residency, crittografia, Vault/HSM, rotazione delle chiavi.

Provider/integrazioni

Invio «Trace-Id »/« Idempotency-Key», pronto per la nuova consegna.
I webhook sono firmati e deduplicati.
Le versioni degli schemi/contratti vengono rispettate (semver, deprecation).

18) Bandiere rosse (anti-pattern)

Il bilanciamento cambia per webhoop senza comando in Ledger.

La mancanza di idepotenza ha causato il doppio dei prelievi/prestiti.

Pubblicare eventi oltre outbox/CDC.

Monolitico senza back-pressure: il picco del traffico fa saltare tutto.

Una miscela di OLTP e rapporti: BI colpisce un database di guerra.

Nessun DLQ/replica; «silenzioso» ingerire errori.

Nessun isolamento regionale PII/denaro; chiavi comuni su più marchi.

Modifica manuale di bilanci/stati nel database.

19) Totale

Fail-safe elaborazione di milioni di transazioni al giorno è su invarianti e disciplina: un'unica fonte di verità, comandi idipotenti, saghe e outbox/CDC, ordine e deducibilità in coda, osservabilità e degrado gestito. Aggiungi i mandati di accesso, le pratiche DR e le esercitazioni regolari - e ottieni un sistema in cui il denaro si muove rapidamente e solo una volta, gli eventi non si perdono e la crescita del traffico e i guasti diventano rischi gestibili anziché sorprese.