[{"data":1,"prerenderedAt":23},["ShallowReactive",2],{"tag-list-fr-distributed-systems":3},[4,15],{"title":5,"description":6,"tags":7,"path":12,"date":13,"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.",[8,9,10,11],"Resilience","Distributed-Systems","Go","Retries","\u002Fbackend\u002Fapi-design\u002Fretry-storms.fr","2026-07-11",null,{"title":16,"description":17,"tags":18,"path":21,"date":22,"img":14},"Pourquoi le rate limiting sur Redis casse à grande échelle (et ce que fait Uber à la place)","Un token bucket en mémoire, c'est trivial. Mettez-le derrière Redis et ça marche, jusqu'à ce que ça ne marche plus. On part du rate limiting sur un seul nœud, puis sur un Redis partagé, on voit pourquoi ce modèle s'effondre à des millions de requêtes par seconde, et le virage qu'a pris Uber : appliquer localement, coordonner globalement, et rejeter par probabilité.",[19,9,10,20],"Rate-Limiting","Performance","\u002Fbackend\u002Fapi-design\u002Frate-limiting-at-scale.fr","2026-07-10",1783842143130]