Lorsque les systèmes échouent, les utilisateurs se moquent de savoir quelle dépendance est hors service. Ils se soucient de savoir si le produit les aide toujours à terminer la tâche pour laquelle ils l'ont ouvert.
C'est pourquoi la dégradation gracieuse compte plus que l'uptime en tant qu'indicateur clé de performance abstrait. Un système peut être partiellement dégradé et conserver la plupart de la valeur utilisateur si les modes de défaillance ont été bien conçus.
À Quoi Ressemble Une Bonne Dégradation
Au lieu d'une page blanche ou d'un modal d'erreur global, un produit résilient peut :
- servir des données de catalogue mises en cache
- cacher un widget secondaire
- afficher du contenu obsolète mais toujours utile
- garder les chemins de lecture disponibles pendant que les chemins d'écriture sont en pause
Ce n'est pas masquer la réalité. C'est décider quelle expérience est moins nuisible lorsqu'une partie de la pile est malsaine.
Pourquoi stale-while-revalidate Est Utile
Le modèle stale-while-revalidate est utile pour le contenu qui change rarement mais est lu constamment.
Cache-Control: s-maxage=60, stale-while-revalidate=86400
Cela indique à un cache intermédiaire qu'il peut continuer à servir du contenu légèrement obsolète tout en essayant de le rafraîchir en arrière-plan. Si le rafraîchissement échoue, les utilisateurs peuvent toujours obtenir une réponse utile au lieu d'une erreur d'origine.
Cela a du sens pour :
- les pages de produit
- la documentation
- le contenu public
Cela a beaucoup moins de sens pour :
- les soldes
- les totaux de commande
- l'état en temps réel très sensible
La Dégradation de l'UI Est Également Importante
La résilience du backend n'est qu'une partie de l'histoire. L'architecture frontend devrait isoler les échecs afin qu'une dépendance fragile ne fasse pas tomber toute la page.
Cela signifie souvent :
- des solutions de repli au niveau des composants
- un rendu partiel
- une communication claire mais calme sur l'état
Lectures Complémentaires