Chaque service externe que votre système appelle sera indisponible à un moment donné. Pas « pourrait l'être » - le sera. La seule question est ce que fait votre système pendant ces minutes-là, et cette question a une bonne réponse par dépendance, pas par système.
Les deux options
Fail closed : la dépendance est tombée, donc l'opération est refusée. Sûr, évident, et ce que fait la plupart du code par accident, parce qu'une exception que personne n'a attrapée se comporte en fail closed par défaut.
Fail open : la dépendance est tombée, donc l'opération continue, et le travail manquant est mis en file d'attente et signalé à un humain. Cela demande une conception délibérée et un endroit où le signalement puisse atterrir.
La question qui tranche
Demandez-vous : si ce tiers est en panne pendant une heure, qui paie ?
Prenez une vérification anti-bot sur un formulaire de rendez-vous. Si le fournisseur n'est pas joignable et que vous êtes en fail closed, vous refusez tout rendez-vous pendant une heure - vous avez transformé la panne de quelqu'un d'autre en chiffre d'affaires perdu pour vous, afin d'éviter peut-être deux formulaires de spam. Passez en fail open, acceptez le rendez-vous, marquez-le comme non vérifié et traitez à la main les quelques mauvais.
Prenez maintenant votre propre rate limiter. S'il tombe, vous n'avez aucun tiers à blâmer, et être en fail open veut dire que vous avez tout simplement coupé une protection précisément dans les conditions où on en a le plus besoin. Celui-là reste en fail closed.
Le schéma qui en ressort est le même dans tous les systèmes que j'ai construits :
- Fail open - l'envoi de SMS et d'e-mails, l'analytique et les événements de pixel, les vérifications anti-bot, la synchronisation de facturation et de comptabilité, le push vers le CRM, la recherche d'adresses. Tout ce dont la valeur est enregistrée ailleurs ou peut être rapprochée plus tard.
- Fail closed - l'autorisation des paiements, l'authentification et les vérifications de session, les vérifications de permissions, vos propres rate limits et validations, et tout ce qui pourrait laisser un client voir les données d'un autre client.
Fail open ne veut pas dire « lancer et oublier »
Le mode de défaillance d'un fail open mal implémenté est pire que le fail closed, parce qu'il est silencieux. Trois choses le rendent honnête :
- L'enregistrement porte l'état -
unverified,invoice_pending- pas un commentaire dans un fichier de log. - Quelque chose réessaie, avec backoff, et abandonne bruyamment plutôt qu'en sourdine.
- Quelqu'un peut voir la file. Un écran d'admin qui liste ce qui attend, avec un compteur, vu par une personne qui remarquera s'il n'est pas à zéro.
Sans le troisième, vous n'avez pas construit de résilience. Vous avez construit un endroit où les problèmes s'accumulent sans que personne ne les trouve.
Écrivez la décision quelque part
La partie qui compte vraiment n'est pas le code. C'est que cette décision se prenne une seule fois, explicitement, pour chaque dépendance - et soit consignée, pour que la personne suivante ne l'inverse pas par accident en réparant autre chose. Un tableau dans le document d'architecture, avec trois colonnes : la dépendance, le comportement et une phrase d'explication. Dix minutes, et cela clôt une discussion qui autrement reviendrait chaque année.
Le même raisonnement vaut pour ce sur quoi cette décision est écrite : un système dont vous ne contrôlez pas les comptes est déjà en fail open, définitivement. C'est l'objet de la note sur ce que vous possédez réellement.