Clés et partitions chaudes

Quand une clé, comme le profil d'une célébrité, reçoit une grosse part du trafic, la partition qui la contient sature pendant que les autres sont au repos. Réplique les clés chaudes, ajoute un suffixe aléatoire ou mets-les en cache près de l'application.

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

  • 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

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