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

Protobuf FieldMask pour l'écriture : un seul endpoint d'update, zéro ambiguïté

Une seule méthode Update qui ne modifie que les champs nommés, sans endpoint par champ ni écrasement du reste. Comment l'update_mask apporte une sémantique PATCH propre à gRPC : mettre à jour, effacer, chemins imbriqués, et le piège du masque vide qui peut effacer des données en silence.

Protobuf FieldMask : laissez vos clients d'API ne demander que ce dont ils ont besoin

Un seul endpoint, plein d'appelants, et des champs parfois très coûteux à produire. Protobuf FieldMask permet à chaque client de déclarer exactement les champs qu'il veut, pour que le serveur saute les requêtes SQL lourdes, les appels distants et le payload inutiles. L'idée, un exemple classique, et les pièges.

Mettre en place un cluster PostgreSQL haute disponibilité à 3 nœuds avec Patroni et etcd

Comment construire un cluster PostgreSQL à 3 nœuds en haute disponibilité avec bascule automatique grâce à Patroni, etcd, HAProxy et Keepalived. L'architecture, les prérequis et le déploiement pas à pas pour qu'une panne de nœud soit gérée sans rien changer côté applications.

Pourquoi j'ai construit ma propre image MongoDB pour faire tourner un replica set en production

Retour d'expérience : déployer un cluster MongoDB replica set à 3 nœuds avec Docker, et pourquoi figer la config dans une image custom au lieu de monter des volumes rend le déploiement reproductible sur des environnements qui ne se ressemblent pas.