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.