[{"data":1,"prerenderedAt":22},["ShallowReactive",2],{"tag-list-fr-resilience":3},[4,15],{"title":5,"description":6,"tags":7,"path":12,"date":13,"img":14},"Algorithmes de load balancing : chacun repare le defaut du precedent","Repartir des requetes sur N serveurs sonne comme un one-liner : choisir un serveur, envoyer la requete. Puis un backend est plus lent, ou plus gros, ou tient une session, et le choix naif s'effondre. On parcourt les algorithmes classiques comme une chaine ou chacun existe pour reparer l'angle mort du precedent : round robin, pondere, least connections, power of two choices, et consistent hashing, en Go, jusqu'a la panne que tous les tutos oublient.",[8,9,10,11],"Load-Balancing","Go","Distributed-Systems","Resilience","\u002Fbackend\u002Fload-balancing\u002Fload-balancing-algorithms.fr","2026-07-20",null,{"title":16,"description":17,"tags":18,"path":20,"date":21,"img":14},"Retry Storms : comment de bons clients font tomber des serveurs en bonne santé","Un retry semble inoffensif : la requête a échoué, on réessaie. Multipliez ça par chaque client, ajoutez une dépendance lente, et les retries deviennent un DDoS auto-infligé. On part de la boucle de retry naïve vers le backoff exponentiel, le jitter, les retry budgets et les circuit breakers, la moitié côté client de la résilience, qui complète le rate limiting côté serveur.",[11,10,9,19],"Retries","\u002Fbackend\u002Fapi-design\u002Fretry-storms.fr","2026-07-11",1786887557961]