slotline

Prenotare uno slot sembra l'inserimento di una riga, e molti sviluppatori lo scrivono esattamente così. Il guaio è che la vera difficoltà non sta nel caso tipico ma nell'unico millisecondo in cui due persone afferrano lo stesso slot libero. slotline è costruito attorno a quell'unico millisecondo, non attorno al modulo di prenotazione.

Tutto il resto della piattaforma, le risorse, il calendario e le viste, avvolge un'unica garanzia: che uno slot abbia esattamente un vincitore. È questo a decidere se il sistema è serio o sembra soltanto funzionare fino alla prima folla.

Un'implementazione ingenua fa due passi: verifica se lo slot è libero, poi lo scrive. Tra questi passi c'è una fessura in cui un secondo utente riesce a vedere lo stesso slot come libero. Entrambi superano la verifica, entrambi scrivono, e hai due prenotazioni per uno slot che nessuno sapeva fossero possibili.

slotline lo tratta come il problema principale da risolvere, non come un caso limite. Il modello del dominio è chiaro proprio perché questa unica garanzia sia ovvia leggendo il codice, non sepolta da qualche parte in uno strato di servizio.

Il vincolo unico sposta la decisione nell'unico posto in cui la concorrenza viene davvero serializzata: il motore del database. Non importa quanti utenti cliccano contemporaneamente, perché il vincitore è deciso da una scrittura atomica, e i perdenti ricevono un errore di conflitto pulito invece di una silenziosa doppia prenotazione.

È facile scrivere un test che prenota una volta e verifica che abbia funzionato. Non dimostra niente, perché non tocca mai la condizione che deve reggere. Il test di valore lancia molti thread sullo stesso slot contemporaneamente e verifica che esattamente uno vinca mentre gli altri ricevono un errore di conflitto pulito.

La verifica è controfattuale: togli il vincolo unico e lo stesso test comincia a lasciar passare due prenotazioni. Se il test resta verde dopo che la protezione è sparita, non stava sorvegliando nulla.

Il risultato è una piattaforma che sotto carico si comporta esattamente come con un solo utente: uno slot ha un proprietario, punto. Non c'è uno stato in cui due persone se ne vanno con lo stesso slot, perché quella possibilità è stata tagliata alla fonte, nel database, non rattoppata nell'interfaccia.