#Go

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.

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.

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é.