Sharding

Situation réelle 10 millions de users, 1TB de data, votre database PostgreSQL rame. Sharding ? Peut-être. Mais avant, explorons toutes les alternatives (plus simples). Ce que j’ai observé : sharding n’est pas premier choix. Alternatives plus simples : Vertical scaling augmenter machine DB actuelle 8 CPU 32GB RAM DB upgradée 32 CPU 256GB RAM Coût $500/mois → $2000/mois Effort 1 heure migration Jusqu’où Machines jusqu’à 128 CPU 4TB RAM existent, Read replicas scaling lecture Master Primary Writes Read replicas R1 R2 R3 Reads Cas usage 90% reads 10% writes Effort 1 semaine, Partitioning même DB tables séparées Partition par date CREATE TABLE orders_2024 PARTITION OF orders FOR VALUES FROM ‘2024-01-01’ TO ‘2025-01-01’ CREATE TABLE orders_2025 PARTITION OF orders FOR VALUES FROM ‘2025-01-01’ TO ‘2026-01-01’ Performance Queries 10x plus rapides partition Effort 1 semaine, Caching agressif Redis cache Requêtes fréquentes Sessions Rate limiting Hit rate 80%+ → Reduce DB load 80%. Quand sharding devient nécessaire : Vertical scaling maxed out Machine biggest available Coût prohibitif >$10k/mois, Write throughput saturé Master CPU >80% Write lag croissant Read replicas suffisent plus, Data size >1TB Backups trop longs >6h Restore impossible RTO Queries lentes malgré index, Geographic distribution Users worldwide Latency critique Data residency laws GDPR. Sharding n’est pas premier choix. Alternatives plus simples : Vertical scaling Read replicas Caching Partitioning. Mais si nécessaire : Choisir bonne stratégie hash range geo, Migration progressive 6-12 mois, Monitoring intensif. Complexité réelle : Cross-shard queries Transactions distribuées Resharding. Commencez simple. Shardez seulement si vraiment requis. ...