📍 Article principal : Hasura DDN + PostgreSQL pour PME. Ce tutoriel met en place une architecture haute disponibilité Hasura avec PostgreSQL répliqué et plusieurs instances Hasura derrière un load-balancer.
Quand le backend devient critique pour le business, l’architecture mono-nœud n’est plus acceptable. Une panne d’une heure pendant les heures ouvrées peut coûter plusieurs millions de XOF en commandes perdues et en confiance client érodée. Hasura supporte nativement le scaling horizontal en mode stateless — déployer plusieurs instances qui partagent la même base PostgreSQL et le même cache de configuration. Côté PostgreSQL, Patroni avec replication streaming permet d’avoir un primaire et plusieurs réplicas avec failover automatique en cas de panne. Ce tutoriel décrit l’architecture complète, le déploiement étape par étape, les tests de bascule, et les bonnes pratiques d’opération.
Prérequis
- Trois VPS distincts (idéalement dans des zones réseau différentes)
- Coolify ou un autre orchestrateur Docker sur chaque VPS
- Familiarité avec PostgreSQL replication et failover
- Connaissance préalable Hasura (voir tutoriel installation) et permissions (voir tutoriel permissions)
- Niveau : avancé senior
- Temps estimé : 8 à 12 heures pour un déploiement complet
Étape 1 — Architecture cible et choix techniques
L’architecture haute disponibilité Hasura repose sur quatre composants. Premièrement, un cluster PostgreSQL avec un primaire en lecture-écriture et un ou deux réplicas en lecture seule, géré par Patroni qui orchestre le consensus via etcd ou Consul. Deuxièmement, PgBouncer en transaction pooling devant le cluster Postgres pour multiplexer efficacement les connexions des instances Hasura. Troisièmement, plusieurs instances Hasura GraphQL Engine v2 stateless qui partagent la même base et la même configuration metadata. Quatrièmement, un load-balancer (Caddy, Traefik ou HAProxy) qui répartit les requêtes GraphQL entre les instances Hasura et gère les health checks.
Cette architecture tolère la panne d’un nœud Hasura (le load-balancer redirige automatiquement vers les instances saines), la panne du primaire Postgres (Patroni promeut un réplica en quelques secondes), et idéalement la panne d’une zone réseau si les trois VPS sont dans des datacenters distincts. Le RTO typique tombe sous 30 secondes pour les pannes Hasura, et sous 2 minutes pour les pannes Postgres avec failover automatique. Le RPO reste proche de zéro grâce à la réplication synchrone Postgres.
Étape 2 — Déployer le cluster Patroni
Patroni est l’outil de référence en 2026 pour gérer un cluster PostgreSQL haute disponibilité. Il utilise un magasin clé-valeur distribué (etcd ou Consul) pour le consensus, surveille la santé du primaire et des réplicas, et déclenche automatiquement la promotion d’un réplica en cas de défaillance. Sur trois VPS, déployer : une instance etcd sur chacun (cluster à trois membres pour le quorum), un Patroni sur chacun configurant la même base PostgreSQL, et un Postgres répliqué.
La configuration Patroni la plus courte tient en 50 lignes YAML par nœud. Les paramètres clés : identifiant unique du nœud, adresse etcd, paramètres PostgreSQL (synchronous_commit, synchronous_standby_names pour la réplication synchrone), seuil de promotion automatique. La documentation officielle Patroni couvre chaque scénario y compris la migration depuis un Postgres single-node existant — précieux quand on bascule une PME en production déjà déployée.
Tester systématiquement le failover après le déploiement : arrêter le nœud primaire, observer Patroni promouvoir un réplica en moins de 30 secondes, vérifier que les écritures continuent sur le nouveau primaire, redémarrer l’ancien nœud qui devient automatiquement réplica. Cette répétition régulière (chaque trimestre) maintient la confiance opérationnelle et détecte les éventuelles dérives de configuration avant qu’elles ne causent une vraie panne.
Étape 3 — Déployer PgBouncer en pooling
Sans pooler, chaque instance Hasura ouvre 50 à 100 connexions Postgres. À trois instances Hasura plus quelques services custom, on dépasse rapidement la limite de 200 connexions par défaut de Postgres et on consomme inutilement de la mémoire. PgBouncer en mode transaction pooling multiplexe efficacement les connexions client en quelques connexions Postgres réelles. Pour Hasura, la configuration recommandée : pool_mode transaction, default_pool_size 25, max_client_conn 1000, server_idle_timeout 600.
Déployer PgBouncer sur le même nœud que Patroni ou sur un nœud dédié devant le cluster. Les instances Hasura pointent leur DATABASE_URL vers PgBouncer (port 6432) au lieu de directement vers Postgres (port 5432). Cette indirection ajoute moins d’une milliseconde de latence et libère drastiquement la pression sur Postgres. Pour les déploiements à très haute charge, déployer plusieurs PgBouncer derrière un proxy TCP comme HAProxy.
Étape 4 — Multi-instance Hasura
Hasura GraphQL Engine v2 est nativement stateless — toutes les instances partagent la même base et la même metadata. Déployer trois conteneurs Hasura identiques sur trois VPS, configurés avec le même DATABASE_URL pointant vers PgBouncer et le même JWT secret. Les instances synchronisent automatiquement leur cache de schéma via les notifications Postgres, donc une modification de metadata appliquée sur une instance se propage en quelques secondes aux autres.
Pour le scaling au-delà de trois nœuds, considérer Hasura Cloud ou DDN qui propose le clustering managé avec sharding du metadata. Mais pour la majorité des PME, trois nœuds suffisent largement à absorber des dizaines de milliers de requêtes par minute sans dégradation.
Étape 5 — Load-balancer Caddy ou Traefik
Devant les trois instances Hasura, un load-balancer répartit les requêtes et gère les health checks. Caddy en mode reverse-proxy multi-upstream avec la directive health_path /healthz retire automatiquement les instances en mauvaise santé du pool. Traefik offre les mêmes fonctionnalités avec une intégration Docker native plus avancée. HAProxy reste la référence pour les déploiements à très haute charge mais demande plus de configuration.
Configurer le load-balancer avec session affinity sur l’identifiant utilisateur quand on utilise les subscriptions WebSocket — cela évite que les déconnexions-reconnexions WebSocket bouclent entre les instances et améliore la stabilité. Pour les requêtes GraphQL standard (HTTP), un round-robin classique suffit largement et maximise la répartition de charge.
Étape 6 — Tests de chaos et validation
Une architecture HA non testée est une architecture HA imaginaire. Mettre en place une procédure trimestrielle de tests de chaos : arrêter brutalement chaque composant un par un et valider que le système continue à servir les utilisateurs. Premier test : arrêter une instance Hasura, vérifier que les autres prennent le relais en moins de 30 secondes. Deuxième test : arrêter le primaire Postgres, vérifier la promotion d’un réplica en moins de 2 minutes et la reprise des écritures. Troisième test : arrêter PgBouncer, vérifier que le load-balancer route vers une instance backup ou que Hasura ouvre des connexions directes Postgres en mode dégradé.
Documenter chaque test avec timestamp, observation du comportement, durée de la dégradation perçue côté client. Cette documentation devient précieuse en cas d’incident réel — l’équipe sait exactement quoi attendre, à quelles métriques surveiller, comment décider d’intervenir manuellement. Sans ces répétitions, la première vraie panne se déroule dans la panique avec un risque élevé d’aggravation par mauvaise manipulation.
Sauvegarde et plan de reprise étendu
Une architecture HA ne dispense pas de la stratégie de sauvegarde — elle la complète. Les sauvegardes protègent contre les corruptions logiques (DROP TABLE accidentel, mise à jour de données erronée, attaque par ransomware) que la haute disponibilité ne couvre pas. Mettre en place trois niveaux. Premier niveau : sauvegarde continue WAL archiving via pgBackRest ou Barman, qui permet le PITR (Point-In-Time Recovery) à la seconde près. Deuxième niveau : dump logique quotidien complet vers un bucket S3 chiffré pour conservation longue. Troisième niveau : snapshot mensuel exporté hors site sur un disque externe ou un coffre cloud distinct.
Tester chaque niveau de sauvegarde une fois par trimestre via une restauration complète sur un VPS de bac à sable identique. La règle : une sauvegarde non testée vaut zéro. Documenter le RTO réel mesuré pour chaque niveau : PITR typique sous 30 minutes, dump logique sous 1 heure, snapshot mensuel sous 4 heures. Ces métriques alimentent le plan de continuité d’activité partagé avec la direction et justifient l’investissement dans l’infrastructure de sauvegarde.
Monitoring et alerting de cluster
Un cluster HA demande une supervision plus fine qu’un mono-nœud. Au-delà des métriques applicatives Hasura, surveiller les métriques cluster : lag de réplication entre primaire et réplicas (alerte si lag > 30 secondes), état du quorum etcd (alerte si moins de 3 nœuds membres), nombre de connexions PgBouncer côté serveur et côté client, taux d’utilisation CPU et mémoire de chaque nœud. Le dashboard Grafana doit afficher l’état de chaque composant sur une vue d’ensemble qui se lit en cinq secondes.
Configurer un système d’astreinte avec rotation hebdomadaire entre les développeurs seniors. Les alertes Pager Duty, OpsGenie ou un simple bot Telegram réveillent l’astreint en cas d’incident critique, avec un runbook qui détaille les étapes de diagnostic et de correction. Cette discipline opérationnelle transforme la PME en organisation mature capable d’opérer une plateforme critique 24/7 sans dépendre du génie individuel d’un développeur indispensable.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Cluster etcd qui perd le quorum | Deux nœuds tombent simultanément | Toujours déployer trois ou cinq nœuds, jamais un nombre pair |
| Failover Postgres qui prend des minutes | Heartbeat Patroni mal configuré | Ajuster ttl=30s et loop_wait=10s pour un failover rapide |
| Instance Hasura zombie reçoit du trafic | Health check trop indulgent | Configurer le health check sur /healthz avec timeout court |
| Subscriptions WebSocket qui bouclent | Session affinity non configurée | Activer sticky sessions sur le load-balancer pour /v1/graphql |
Adaptation au contexte ouest-africain
Pour une PME ouest-africaine, le coût de cette architecture HA reste accessible — trois VPS Hetzner CCX13 à 30 €/mois chacun, soit 90 €/mois total pour une infrastructure résiliente capable d’absorber des pannes datacenter. Pour les déploiements souverains, déployer chez Wagaden Dakar et un partenaire CI pour avoir des nœuds dans deux pays distincts — la latence de réplication reste sous 30 ms entre Dakar et Abidjan, parfaitement compatible avec une réplication synchrone. Cette dispersion géographique offre une résilience supplémentaire face aux risques régionaux (panne Sonatel généralisée par exemple).
Coût détaillé et ROI
Décomposer le coût total d’une infrastructure HA pour une PME. Trois VPS Hetzner CCX13 à 32 €/mois chacun, soit 96 €/mois : 1 152 €/an. Stockage Storage Box pour sauvegardes : 4 €/mois, soit 48 €/an. Outils de monitoring auto-hébergés (Grafana, Prometheus) gratuits. Total annuel autour de 1 200 €, soit environ 800 000 XOF. À comparer aux 2 à 5 millions de XOF de pertes potentielles sur une seule panne pendant les soldes Tabaski ou un Black Friday adapté. Le ROI tombe en quelques mois pour une PME au-dessus de 50 millions de XOF de chiffre d’affaires annuel.
Pour les PME plus petites, démarrer en mono-nœud reste raisonnable et bascule en HA quand le palier critique est franchi. La transition se fait sans rupture si l’architecture monolithique a été bien conçue : PostgreSQL dédié dès le départ, configuration externalisée, sauvegardes testées. La PME peut ainsi passer en quelques jours d’une architecture simple à une architecture HA quand le besoin se présente, sans refonte majeure du code applicatif.
Migration depuis mono-nœud vers HA
Pour les PME qui ont déjà un Hasura mono-nœud en production et veulent basculer en HA sans interruption, la procédure tient en quatre phases sur deux à trois semaines. Phase 1, déployer le cluster Patroni sur trois nouveaux VPS et synchroniser la base via réplication initiale en arrière-plan, sans toucher à la production. Phase 2, ajouter PgBouncer en façade, déployer une nouvelle instance Hasura qui pointe vers ce PgBouncer, et la mettre en écoute sans trafic réel encore.
Phase 3, configurer le load-balancer pour répartir progressivement le trafic — 10 % vers la nouvelle infrastructure, surveiller pendant une semaine, monter à 50 %, puis 100 %. Phase 4, décommissionner l’ancienne infrastructure mono-nœud après validation complète, conserver une snapshot finale pour archive. Cette migration progressive sans coupure est l’art du DevOps moderne — la PME bascule sa colonne vertébrale technique sans que les utilisateurs ne perçoivent quoi que ce soit, signe d’une équipe technique mature.
L’investissement initial dans la haute disponibilité paie des dividendes opérationnels à long terme bien au-delà du simple uptime mesuré : équipe technique sereine, clients confiants, capacité d’absorber la croissance sans douleur, image professionnelle face aux partenaires institutionnels.
Pour aller plus loin
🔝 Retour à l’article principal : Hasura DDN + PostgreSQL pour PME. Tutoriels précédents : déployer Hasura sur Coolify, permissions row-level, intégrer Mobile Money.
Documentation Patroni : patroni.readthedocs.io, PgBouncer : pgbouncer.org. Une PME qui investit dans cette architecture HA construit un avantage compétitif structurel. Quand un concurrent connaît une panne de plusieurs heures pendant le pic des soldes Tabaski, la PME équipée HA continue à servir ses clients sans interruption — quelques milliers de XOF de plus par mois en infrastructure peuvent capter des dizaines de milliers de XOF en chiffre d’affaires additionnel sur ces moments critiques. Cette logique du pic résiste mieux que tous les calculs de coût moyen et justifie l’investissement initial dans l’architecture résiliente dès que la PME franchit le seuil des 10 millions de XOF de chiffre d’affaires mensuel.