Comment Instagram sert 2 milliards d'utilisateurs sur Postgres : sharding, PgBouncer et identifiants Snowflake

La vidéo s'ouvre sur une provocation : Instagram sert 2 milliards d'utilisateurs sur Postgres, tandis que Reddit, Notion, Discord et Strava maintiennent eux aussi une grande partie de leur charge sur Postgres. Tous ont évalué les alternatives, tous sont restés. La question s'impose naturellement : que savent ces équipes que le mantra « Postgres ne passe pas à l'échelle » ignore ?

L'histoire commence en 2010 : trois ingénieurs, des machines virtuelles louées, un stockage d'objets pour les photos et un seul Postgres pour tout le reste (comptes, métadonnées, commentaires, likes, graphe d'abonnements). À 10 millions d'utilisateurs en 2011, le tableau est inchangé. À l'acquisition d'un milliard de dollars en 2012, il y a 27 millions d'utilisateurs sur une seule base de 2 téraoctets. La leçon que la vidéo garde pour la fin germe ici : une technologie ennuyeuse bien exploitée bat une technologie nouvelle mal exploitée.

En 2012, la machine unique atteint son plafond : le plus gros serveur louable de l'époque manque de mémoire, le débit disque est saturé, il n'y a plus nulle part où monter en puissance verticalement. Le réflexe que la vidéo recommande compte : au lieu de changer de base de données dans la panique, identifier précisément ce qui est engorgé et corriger cela. Et le premier engorgement s'avère différent de ce que la plupart des gens devinent.

Le premier mur n'est pas la taille des données, ce sont les connexions. Chaque connexion occupe environ 1,3 mégaoctet ; quand des dizaines de serveurs applicatifs ouvrent chacun leur propre petit pool (l'exemple détaillé est 50 serveurs fois 30 connexions), on obtient 1500 connexions consommant 2 gigaoctets avant qu'une seule requête utile ne s'exécute. La solution est PgBouncer : un proxy léger entre l'application et la base de données qui multiplexe des milliers de connexions entrantes sur quelques dizaines de connexions réelles. La mémoire revient au cache de pages, au tri et à la planification des requêtes. L'affirmation est tranchée : pour toute configuration Postgres sérieuse sans pooler, c'est la correction au meilleur rendement de la semaine.

Le pooling achète un répit, mais la charge continue de croître et le refrain habituel arrive : « il est temps de passer au NoSQL ». La vidéo rejette cette prescription, arguant que la douleur du partitionnement ne disparaît pas sur Cassandra, elle se cache simplement derrière une autre abstraction. Et il n'y a pas de billet retour : une fois la bascule effectuée, revenir en arrière est presque impossible. Instagram décide plutôt de rendre Postgres lui-même horizontal.

La décision de sharding est prise, mais la clé de sharding scelle son destin. Le candidat naturel est l'identifiant utilisateur : les photos et les likes d'un utilisateur vivent sur un seul shard, « afficher mon profil » ne touche qu'un seul shard, rapide et propre. Mais la requête déterminante d'un réseau social est « afficher les photos des personnes que je suis », et quand 200 abonnements se répartissent sur 50 shards, cela devient un cauchemar : fanout vers 50 bases de données, fusion et tri dans la couche applicative, un fil aussi lent que le shard le plus lent, des modes de défaillance inédits. Le compromis est permanent ; l'équipe parie qu'elle peut résoudre les requêtes inter-utilisateurs dans la couche applicative avec du cache, un fanout intelligent et des fils précalculés.

Voici l'idée que la vidéo qualifie de « l'architecture elle-même » : séparer la manière dont les données sont partitionnées de l'endroit où elles résident physiquement. L'équipe définit quelques milliers de shards logiques (des schémas Postgres avec des tables identiques), tous hébergés au départ sur une seule machine physique. L'application demande seulement « quel shard logique possède cet utilisateur ». Quand une machine se remplit, aucune donnée n'est réécrite ; les shards logiques sont copiés vers une nouvelle machine grâce à la réplication en flux intégrée et la table de correspondance est mise à jour (dans l'exemple, la moitié de la plage de shards d'un nœud presque plein migre vers le nouveau nœud et les deux se stabilisent à mi-capacité). Le nombre de shards n'étant jamais codé en dur, la croissance devient un simple changement de configuration.

Les compteurs classiques à auto-incrémentation entrent immédiatement en collision dans cette disposition : si chaque shard génère sa propre série 1-2-3, deux photos différentes partagent un même identifiant. Les identifiants aléatoires de 128 bits sont énormes et non ordonnés, ce qui rend les requêtes temporelles coûteuses ; un serveur central de tickets est un point de défaillance unique ; un service Snowflake externe est une chose de plus à surveiller. La réponse d'Instagram est un nombre de 64 bits en trois parties : un horodatage en millisecondes de 41 bits à partir d'une époque personnalisée (41 ans de marge), un identifiant de shard de 13 bits (jusqu'à 8 mille shards), une séquence par milliseconde de 10 bits (des centaines de milliers d'identifiants par seconde et par shard). Il s'exécute comme une petite fonction Postgres sur chaque shard, sans coordination ni dépendance externe ; l'horodatage étant dans les bits de poids fort, trier par identifiant signifie du plus récent au plus ancien, sans index temporel séparé. Ce modèle s'est ensuite répandu dans l'industrie jusqu'à Discord et Slack ; l'avertissement pratique est de l'adopter dès le premier jour, pas après un milliard de lignes.

La vidéo met également en lumière trois fonctionnalités sous-utilisées déjà présentes dans Postgres. Les index partiels : indexer seulement les 30 derniers jours d'une table d'un milliard de lignes réduit l'index d'un facteur dix et le maintient petit à mesure que les anciennes données expirent. Les index fonctionnels : indexer les 8 premiers caractères d'un jeton de 64 caractères au lieu de la chaîne entière garde les recherches rapides pour un dixième de la taille. La réplication logique : diffuser chaque insertion, mise à jour et suppression vers l'index de recherche, l'invalidation de cache et l'entrepôt d'analytique en temps réel, au lieu de construire à la main des doubles écritures et des files dans l'application.

Une note d'honnêteté : c'est l'histoire de 2010-2015 ; après l'acquisition, le graphe d'abonnements d'Instagram a migré vers l'infrastructure de Meta et vit aujourd'hui dans TAO, un système de graphe distribué. Mais les cinq règles de la vidéo restent valables : ne pas sharder avant d'y être forcé (l'équipe a attendu 27 millions d'utilisateurs), séparer le logique du physique, adopter des identifiants façon Snowflake dès le premier jour, corriger d'abord le pooling de connexions, et n'acheter une nouvelle infrastructure que pour des problèmes réellement nouveaux (recherche vectorielle, séries temporelles, graphes). La thèse finale : le goulot d'étranglement n'est jamais la base de données, c'est l'architecture qui l'entoure.