> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2025/w46-database-migration-case-study.md).

# W46-Étude de cas d'une migration de base de données

J'ai lu [Comment nous avons migré un milliard d'enregistrements de DB1 vers DB2 sans interruption](https://medium.com/@himanshusingour7/how-we-migrated-db-1-to-db-2-1-billion-records-without-downtime-c034ce85d889), un retour sur la migration sans arrêt d'un cluster financier d'un milliard d'enregistrements.

J'y retrouve beaucoup de nos principes de maîtrise des risques techniques : avancer progressivement, avec des étapes vérifiables et réversibles indépendamment. Donner la priorité à l'observabilité, depuis les journaux WAL et les taux de succès du cache jusqu'aux commandes et aux flux de revenus, permet de détecter les anomalies à temps. J'ai aussi découvert une méthode ingénieuse pour les migrations de bases ou de services backend : les Shadow Reads.

Une migration est, au fond, un problème complexe de conception système. L'auteur présente cinq choix importants.

D'abord, migrer en masse les données froides en les partitionnant, en parallélisant les traitements et en désactivant les index.

Ensuite, introduire une double écriture avec une file de nouvelles tentatives Kafka pour synchroniser le trafic en temps réel entre ancienne et nouvelle base, tout en préservant l'idempotence.

Troisièmement, vérifier en production avec les Shadow Reads. Les requêtes utilisateur lisent toujours l'ancienne base, mais chaque requête est exécutée discrètement en arrière-plan sur la nouvelle pour comparer les résultats. Durant plusieurs semaines, cette méthode a révélé des problèmes impossibles à détecter en test : traitement des fuseaux horaires, comportement par défaut des valeurs NULL, règles de tri des caractères. J'ai ensuite pensé que la migration de l'architecture backend du paiement l'an dernier utilisait probablement une méthode similaire. Elle reste difficile à reproduire côté frontend.

Quatrièmement, basculer prudemment pendant une période de faible trafic, avec préchauffage du cache, plan de retour arrière et surveillance étroite.

Enfin, l'auteur souligne l'importance d'une forte observabilité pendant toute la migration.

Les Shadow Reads s'appliquent difficilement au frontend, car chaque visite utilise une version exclusive : un utilisateur sur la nouvelle version ne consulte pas l'ancienne. En base, on compare invisiblement des jeux de résultats. La justesse du frontend dépasse largement la cohérence des données : interactions, performance ressentie, cohérence de l'accessibilité et compatibilité entre appareils manquent tous de moyens de vérification peu coûteux. Déploiement progressif du trafic, analyse des comportements, suivi des indicateurs métier et vérification manuelle restent les outils les plus efficaces.