Il click day che non può fare overbooking
Un "click day" a tempo: migliaia di utenti in gara per posti a capienza fissa, picchi di traffico sugli stessi posti nello stesso secondo, un vincolo non negoziabile — mai superare la capienza.
La sfida
In un evento di iscrizioni competitivo i due modi di fallire sono entrambi fatali: assegni un posto in più e tradisci la promessa fatta a una persona reale; vai giù sotto carico e l'evento fallisce pubblicamente. Il sistema doveva assorbire il picco, restare equo ed essere dimostrabilmente corretto.
Architettura
Il percorso caldo non aspetta mai SQL; SQL non si fida mai ciecamente di Redis.
Cosa lo ha reso possibile
- Prenotazione Redis-first: un token bucket in Lua come percorso primario — atomico, veloce, fatto per la contesa.
- Degrado onesto: un circuit breaker devia su un percorso SQL transazionale a row lock quando Redis non risponde, e uno sweeper ripulisce le prenotazioni abbandonate.
- Stato che si ripara da solo: una riconciliazione ogni 60 secondi, con leader election, riallinea i contatori Redis al database agendo solo su drift confermato due volte di fila.
- Verifica di livello contrattuale: piano di test firmato dal cliente, suite k6 con helper unit-tested, dashboard di monitoring e runbook operativo.
- Il guasto si prova, non si teme: un failover di Redis provocato di proposito a metà test non ha causato alcun degrado misurabile.
- Collo di bottiglia trovato con metodo: una fleet di VM di carico ha isolato il breaking point a 6–7k utenti simultanei; un A/B a variabile singola ha dimostrato che era il database, non l'app, il livello da scalare.
Risultato
L'evento è andato in scena su uno stack Cloud Run + Cloud SQL + Memorystore interamente su Terraform, con scaling pre-evento attivabile da un flag. Nella run di carico target — 2.000 utenti simultanei per un'ora piena, oltre 700k journey completi — le linee contese si sono riempite esattamente fino alla capienza, verificato con query dirette sul database. Zero posti in più, zero errori.