Sharding

Diviser la donnée et le trafic sur N instances indépendantes au lieu de tout faire tenir sur une seule.

Problème

Un service ou une DB monte en charge linéairement avec les ressources jusqu'à atteindre les limites d'une instance unique (CPU, RAM, IOPS, bande passante). La scale verticale coûte exponentiellement plus cher au-delà de certains seuils et plafonne. La scale horizontale par sharding distribue la charge mais introduit des contraintes nouvelles : requêtes cross-shard, transactions distribuées, rebalancing.

Forces

• Une instance unique a un plafond CPU/RAM/IOPS atteignable.
• Une partition trop grosse (hot shard) annule le bénéfice du sharding.
• Les requêtes cross-shard sont coûteuses voire impossibles.
• Les transactions distribuées (2PC, Saga) doivent remplacer les transactions locales.
• Le rebalancing déplace de la donnée et impacte les performances.

Solution

Partitionner les données par une shard key qui détermine le shard cible. Chaque shard est une instance complète et autonome qui héberge un sous-ensemble strictement disjoint des données. Un routeur (proxy ou lib client) calcule le shard à partir de la clé. Trois stratégies dominantes existent (voir ci-dessous). Le pattern marche pour les DB (Postgres Citus, MongoDB, Cassandra), les caches (Redis Cluster), les queues (Kafka partitions), et les services applicatifs (un hub EDI par région).

Stratégies de sharding

• Hash-based — shard = hash(key) % N ou via consistent hashing. Distribution uniforme, mais requêtes range impossibles. Bon pour user_id, partner_id.
• Range-based — chaque shard héberge un intervalle de clés (par date, par région). Permet les requêtes range, mais risque de hot shards (la dernière partition de temps reçoit toutes les écritures).
• Lookup-based — une table de routage (shard_map) mappe clé → shard. Très flexible (on peut déplacer une seule clé), mais le lookup ajoute une indirection et la table doit être HA.

Implémentation EDI

Un hub EDI multi-tenants à très haute volumétrie shard par tenant : shard = hash(partnerId). Chaque shard a sa propre DB Postgres, sa propre file Kafka. Conséquence : un partenaire chaotique (Walmart en peak hour Black Friday) ne fait pas tomber les autres. La règle est de toujours shard sur une clé qui contient le tenant : commandes, factures, messages AS2. Pour les requêtes globales (KPI hub-wide), on agrège asynchronement vers un data lake (cf. Data Mesh).

Anti-patterns

• Sharding sans hot key analysis — un compte premium fait tomber son shard.
• Shard key qui change au cours de la vie d'une row — il faut déplacer l'objet.
• Requêtes cross-shard fréquentes — on annule le gain de la partition (fan-out coûteux).
• Rebalancing synchrone bloquant — il faut un mécanisme online.
• Trop de shards (over-sharding) — overhead de coordination dépasse le gain.

Patterns liés

• Consistent Hashing — algorithme typique pour le hash-based sharding.
• Bulkhead — isolation logique entre shards.
• Saga Orchestration — remplace les transactions distribuées synchrones.
• CQRS — souvent combiné, le shard d'écriture diffère du shard de lecture.

Sources

• Microsoft Azure Architecture — Sharding pattern. learn.microsoft.com/en-us/azure/architecture/patterns/sharding
• Kleppmann M. — Designing Data-Intensive Applications, O'Reilly 2017, chap. 6 « Partitioning ».
• Newman S. — Building Microservices, 2^e éd., O'Reilly 2021, chap. 15 « Scaling Microservices ».