🐘 Cas 3 – Shardigs

Symptômes objectifs

• Temps de backup/restore incompatible avec le RTO demandé.
• Fenêtres de maintenance (VACUUM FULL, REINDEX, upgrades) qui dépassent la plage acceptée.
• Contestion persistante (I/O, locks, CPU) malgré :
  • tuning mémoire & autovacuum,
  • partitionnement interne PostgreSQL,
  • read-replicas, cache applicatif.

-- Estimation du temps de backup actuel
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;
          

Si le restore d’un dump complet dépasse plusieurs heures et qu’on exige un RTO < 1h, le sharding (ou au moins la séparation fonctionnelle) devient un sujet sérieux.

Questions à se poser

• Peut-on isoler les plus gros tenants / clients sans casser tout le modèle de données ?
• Y a-t-il des domaines métier quasi indépendants (billing, logs, analytics) ?
• La charge est-elle principalement en lecture, en écriture ou mixte ?

Red flags

• Tout est centralisé dans une seule DB « fourre-tout » sans séparation claire.
• Les scripts de maintenance prennent des jours pour tourner sur l’ensemble de la base.
• Chaque croissance de trafic impose un scale-up matériel coûteux.

Sharding fonctionnel

Sharding par tenant

• Chaque gros client (tenant) dispose de sa DB ou de son schéma dédié.
• Permet d’isoler les clients les plus lourds sur des clusters séparés.

Range / hash sharding

• Range : distribution par plages de clé (id, date, tenant_id).
• Hash : distribution uniforme via hash(key) mod N.

-- Concept hash sharding applicatif (pseudo-code)
shard_id = hash(tenant_id) % N
cluster  = shard_map[shard_id]
CONNECT TO cluster;
          

Critères de choix

• Besoin de jointures fortes entre tenants ? → éviter le hash sharding brut.
• Volumétrie par tenant très inégale ? → sharding fonctionnel + par tenant sur les « gros » seulement.
• Équipe et outillage : un sharding simple + bien outillé vaut mieux qu’un design théoriquement parfait mais ingérable.

Catalogue des shards

• Table (ou service) centrale décrivant :
  • la liste des shards,
  • leur adresse / DSN,
  • leur plage de clé (range) ou tenants associés.
• Versionnée, auditable, mise à jour via scripts d’admin, pas directement en prod par hasard.

CREATE TABLE shard_catalog (
  shard_id    int PRIMARY KEY,
  dsn         text NOT NULL,
  key_range   tstzrange,   -- ou int4range / int8range
  tenants     int[]
);
          

Routage applicatif / middleware

• Layer dans l’ORM ou un service dédié qui :
  • résout le shard à partir du tenant / clé,
  • ouvre la connexion vers ce shard,
  • gère le failover et la répartition lecture/écriture.
• Éviter le routage « ad hoc » dans tous les coins du code.

-- Pseudo-code de routing
shard = find_shard_for_tenant(tenant_id)
conn  = pool.get_connection(shard.dsn)
conn.execute(query, params)
          

Éviter le 2PC partout

• Le two-phase commit cross-shards est complexe et coûteux.
• Réserver aux cas rares où une transaction doit être strictement atomique.

Sagas & orchestrateurs

• Enchaîner plusieurs étapes sur différents shards.
• Pour chaque étape, prévoir une action de compensation (rollback fonctionnel).

Patterns d’intégration

• Évènements de domaine : un shard publie un évènement, un autre shard réagit en asynchrone.
• CQRS : lecture agrégée dans une vue matérialisée dédiée, alimentée par les évènements.

L’objectif n’est pas d’avoir une consistance immédiate partout, mais une consistance suffisante avec un modèle d’erreur maîtrisé (replays, compensations, timeouts).

Phase 1 – Analyse & découpage

1. Cartographier les domaines métier, tables volumineuses, tenants lourds.
2. Définir la stratégie (fonctionnel, tenant, range/hash).
3. Identifier les jointures critiques qui deviendront cross-shards.

Phase 2 – POC & pilote

• Mettre en place un petit nombre de shards.
• Déplacer un sous-ensemble de données (un tenant pilote, un domaine) et tester :
• latence, procédure de secours, bascule de trafic, reporting.

Phase 3 – Bascule progressive

1. Mettre en place la replication / synchronisation initiale (logical replication, ETL…).
2. Bascule par lots (tenants / domaines), avec possibilité de rollback.
3. Nettoyage progressif de l’ancienne base monolithique.

À documenter

• Procédure de création d’un nouveau shard.
• Procédure de rebalancing (déplacer un tenant d’un shard à un autre).
• Procédure de désastre (perte d’un shard isolé).