Cohérence éventuelle

Si les écritures s'arrêtent, tous les réplicas finissent par converger vers la même valeur, mais entre-temps les lectures peuvent être périmées. Acceptable pour des likes ou des compteurs de vues, dangereux pour un solde bancaire.

Où on le retrouve dans les vrais systèmes

  • Base clé-valeur

    Les données sont réparties entre partitions selon le hachage de la clé : le débit croît presque sans limite tant que les clés sont bien distribuées. Une clé très populaire atteint la limite de sa partition et se fait throttler. Le mode à la demande suit le trafic mais throttle les sauts brusques au-delà du double du pic précédent.

    En production : Amazon DynamoDB, Azure Cosmos DB, Google Bigtable, Riak, FoundationDB

  • Base documentaire

    Un replica set élit un nouveau primaire quand le primaire tombe. Avec un write concern majority, une écriture confirmée survit au basculement ; avec w:1, les écritures récentes peuvent être annulées. Lire sur les secondaires augmente la capacité mais renvoie des données un peu périmées.

    En production : MongoDB Atlas, Amazon DocumentDB, Couchbase, Firestore

  • Moteur de recherche

    Un document devient trouvable après le prochain rafraîchissement : la recherche est éventuellement cohérente avec ta base principale. Les requêtes consomment beaucoup de CPU ; ajoute des nœuds et des réplicas pour le débit, et garde la source de vérité ailleurs.

    En production : Elasticsearch, OpenSearch, Apache Solr, Algolia, Meilisearch

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable