Région d'origine et transfert des écritures

Chaque enregistrement a une région d'origine qui détient ses écritures, souvent pour des raisons légales ou de cohérence. Les autres régions servent les lectures depuis des copies locales et transmettent les écritures à la région d'origine de façon asynchrone, en échangeant quelques secondes de fraîcheur contre une latence locale.

Où on le retrouve dans les vrais systèmes

  • Cache en mémoire

    Le taux de hit dépend de la part du working set qui tient en mémoire, du TTL et de la politique d'éviction. Si le cache tombe ou est vidé, toutes les lectures tombent d'un coup sur la base : prévois cette ruée. Le write-behind est rapide mais perd des écritures si un nœud meurt sans réplica.

    En production : Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly

  • File de messages

    Une file absorbe les pics : l'API répond dès que le message est stocké, et les workers vident l'arriéré à leur rythme. Les files standard livrent au moins une fois et peuvent réordonner ; les files FIFO gardent l'ordre mais plafonnent le débit. Les messages qui échouent à répétition partent en dead-letter.

    En production : Amazon SQS, RabbitMQ, Azure Service Bus, Google Cloud Tasks

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