#Distributed-Systems

Comment le verrouillage à deux phases empêche vos transactions bancaires concurrentes de corrompre vos données

Deux virements touchent le même compte à la même milliseconde et un paiement s'évapore. C'est la mise à jour perdue, et c'est pour ça que tout registre de paiement repose sur une couche de contrôle de concurrence. Cet article construit la théorie depuis un exemple fintech jusqu'au verrouillage à deux phases (2PL) : le modèle de transaction, les maths de la conflit-sérialisabilité et le graphe de précédence, pourquoi le théorème du 2PL garantit la correction, le contrôle pessimiste contre optimiste dans PostgreSQL, le 2PL strict, et comment les interblocages sont détectés et évités.

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.

Zanzibar demystifie : comment Google repond a 'cet utilisateur a-t-il le droit ?'

L'autorisation ressemble a un if d'une ligne, jusqu'a ce qu'on l'execute dix millions de fois par seconde sur tous les produits de Google. Zanzibar est le systeme qui a rendu cette question rapide, coherente et globale. On part du controle de permission naif pour arriver au controle d'acces base sur les relations, au modele de tuples, a la coherence avec les zookies, et aux heritiers open source comme OpenFGA que vous pouvez utiliser des aujourd'hui.

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