Varje extern tjänst ditt system anropar kommer att vara otillgänglig vid något tillfälle. Inte ”skulle kunna bli” - kommer att bli. Den enda frågan är vad ditt system gör under de minuterna, och den frågan har ett rätt svar per beroende, inte per system.
De två alternativen
Fail closed: beroendet ligger nere, alltså nekas operationen. Säkert, uppenbart, och vad det mesta av all kod gör av misstag, eftersom ett undantag som ingen fångar gör fail closed som standard.
Fail open: beroendet ligger nere, alltså fortsätter operationen, och det återstående arbetet läggs i kö och markeras för en människa. Kräver medveten design och en plats där markeringen kan landa.
Frågan som avgör
Fråga dig: om den här tredje parten ligger nere i en timme, vem betalar?
Ta en botkontroll på ett bokningsformulär. Om leverantören inte går att nå och du gör fail closed nekar du varje bokning i en timme - du har förvandlat någon annans avbrott till dina förlorade intäkter, för att undvika kanske två spamformulär. Gör fail open, acceptera bokningen, markera den som overifierad och ta hand om de få dåliga för hand.
Ta nu din egen rate limiter. Om den fallerar finns det ingen tredje part att skylla på, och fail open betyder att du helt enkelt har stängt av ett skydd exakt under de förhållanden där det mest sannolikt behövs. Den gör fail closed.
Mönstret som faller ut är detsamma i varje system jag har byggt:
- Fail open - leverans av SMS och e-post, analytics och pixelhändelserna, botkontrollerna, synkroniseringen av fakturering och bokföring, push till CRM, adressuppslagning. Allt vars värde registreras någon annanstans eller kan stämmas av senare.
- Fail closed - betalningsauktorisering, autentiseringen och sessionskontrollerna, behörighetskontrollerna, dina egna rate limits och valideringar, och allt som skulle låta en kund se en annan kunds data.
Fail open betyder inte ”släpp och glöm”
Felläget hos en dåligt implementerad fail open är värre än fail closed, för det är tyst. Tre saker gör det ärligt:
- Posten bär tillståndet -
unverified,invoice_pending- inte en kommentar i en loggfil. - Något gör om försöket, med backoff, och ger upp högljutt, inte i det tysta.
- Någon kan se kön. En adminskärm som listar vad som väntar, med ett antal, sedd av en människa som märker om det inte är noll.
Utan den tredje har du inte byggt resiliens. Du har byggt en plats där problem samlas på hög utan att någon hittar dem.
Skriv ner beslutet
Delen som verkligen betyder något är inte koden. Det är att det här beslutet fattas en enda gång, uttryckligen, för varje beroende - och dokumenteras, så att nästa person inte vänder på det av misstag medan något annat lagas. En tabell i arkitekturdokumentet med tre kolumner: beroendet, beteendet och en mening om varför. Tio minuter, och det avslutar en diskussion som annars skulle tas upp igen varje år.
Samma resonemang gäller det som beslutet är skrivet på: ett system vars konton du inte kontrollerar har redan gjort fail open, permanent. Det är vad anteckningen om vad du faktiskt äger handlar om.