Ogni servizio esterno che il tuo sistema chiama sarà indisponibile a un certo punto. Non "potrebbe" - sarà. L'unica domanda è che cosa fa il tuo sistema in quei minuti, e questa domanda ha una risposta giusta per dipendenza, non per sistema.
Le due opzioni
Fail closed: la dipendenza è giù, quindi l'operazione viene rifiutata. Sicuro, ovvio, e quello che gran parte del codice fa per caso, perché un'eccezione che non ha catturato nessuno fa fail closed di default.
Fail open: la dipendenza è giù, quindi l'operazione continua, e il lavoro rimasto va in coda e viene segnalato a una persona. Richiede un design deliberato e un posto dove la segnalazione possa arrivare.
La domanda che decide
Chiediti: se questo terzo è giù per un'ora, chi paga?
Prendi una verifica anti-bot su un modulo di prenotazione. Se il provider non è raggiungibile e fai fail closed, rifiuti qualsiasi prenotazione per un'ora - hai trasformato il guasto di qualcun altro nel tuo mancato incasso, per evitare forse due invii di spam. Fai fail open, accetta la prenotazione, marcala come non verificata e occupati a mano dei pochi invii cattivi.
Ora prendi il tuo rate limiter. Se cede, non hai nessun terzo a cui dare la colpa, e fare fail open significa che hai semplicemente spento una protezione esattamente nelle condizioni in cui è più probabile che serva. Quello fa fail closed.
Lo schema che ne esce è lo stesso in ogni sistema che ho costruito:
- Fail open - l'invio di SMS ed email, analytics ed eventi di pixel, le verifiche anti-bot, la sincronizzazione di fatturazione e contabilità, il push verso il CRM, la ricerca di indirizzi. Qualsiasi cosa il cui valore è registrato altrove o può essere riconciliato più tardi.
- Fail closed - l'autorizzazione dei pagamenti, l'autenticazione e le verifiche di sessione, le verifiche dei permessi, i tuoi rate limit e le tue validazioni, e qualsiasi cosa che lascerebbe un cliente vedere i dati di un altro cliente.
Fail open non significa "lancia e dimentica"
Il modo in cui cede un fail open implementato male è peggiore del fail closed, perché è silenzioso. Tre cose lo rendono onesto:
- Il record porta lo stato -
unverified,invoice_pending- non un commento in un file di log. - Qualcosa riprova, con backoff, e si arrende rumorosamente, non in sordina.
- Qualcuno può vedere la coda. Una schermata di admin che elenca quello che è in attesa, con un numero, vista da una persona che noterà se non è zero.
Senza il terzo, non hai costruito resilienza. Hai costruito un posto in cui si accumulano problemi che non troverà nessuno.
Scrivi la decisione da qualche parte
La parte che conta davvero non è il codice. È che questa decisione si prende una volta sola, esplicitamente, per ogni dipendenza - e viene messa per iscritto, così che la persona successiva non la inverta per sbaglio mentre ripara altro. Una tabella nel documento di architettura, con tre colonne: la dipendenza, il comportamento e una frase sul perché. Dieci minuti, e chiude una discussione che altrimenti si riaprirebbe ogni anno.
Lo stesso ragionamento vale per la cosa su cui la decisione è scritta: un sistema di cui non controlli gli account ha già fatto fail open, in modo permanente. È l'argomento della nota su cosa possiedi davvero.