Comment Instagram a atteint 14 millions d’utilisateurs avec seulement 3 ingénieurs

• D’octobre 2010 à novembre 2011, soit en environ un an, Instagram est passé de 0 à 14 millions d’utilisateurs. L’équipe d’ingénierie ne comptait que 3 personnes
• Ils ont suivi 3 principes
  • Garder les choses très simples (Keep things very simple.)
  • Ne pas réinventer la roue (Don’t re-invent the wheel.)
  • Utiliser des technologies éprouvées et solides quand c’est possible (Use proven, solid technologies when possible.)

Aperçu simple de la stack du point de vue utilisateur

• L’infrastructure initiale reposait sur Ubuntu Linux sur AWS EC2
• L’application Instagram est d’abord sortie uniquement sur iOS, et comme c’était avant l’annonce de Swift, il est très probable qu’elle utilisait Objective-C + UIKit
• Pour l’équilibrage de charge, ils utilisaient Amazon Elastic Load Balancer et 3 instances NGINX
• Backend
  • Les serveurs applicatifs étaient développés en Python, avec Django et le serveur WSGI Gunicorn
  • Avec Fabric, ils exécutaient simultanément les mêmes commandes sur plusieurs instances, ce qui permettait de déployer le code en quelques secondes
  • 25 machines Extra-Large à CPU haute performance étaient en service. Elles étaient toutes stateless, donc faciles à ajouter si nécessaire
• Stockage des données générales
  • ID photo associés, photo réelle correspondant à cet ID, et données utilisateur liées à la photo
  • Les serveurs applicatifs récupéraient les données depuis PostgreSQL
  • Pooling entre Django et PostgreSQL via pgbouncer
  • Instagram utilisait des ID triables par le temps : 41 bits pour les millisecondes + 13 bits pour l’ID de shard + 10 bits pour une séquence auto-incrémentée
• Stockage des photos : S3 et CloudFront
• Cache : Redis et Memcached
  • Grâce à un hachage intelligent, ils stockaient le mapping de 300 millions de clés dans moins de 5 Go d’espace
  • Puis, deux ans plus tard, Facebook a publié un article expliquant comment il avait fait monter Memcached à l’échelle pour traiter des dizaines de milliards de requêtes par seconde
• PostgreSQL et Redis fonctionnaient tous deux en mode master-replica. Les sauvegardes étaient réalisées en continu avec des snapshots Amazon EBS
• Push notifications et tâches asynchrones : pyapns pour les notifications, Gearman comme file de tâches
• Pour surveiller les erreurs en temps réel, ils utilisaient Sentry, une application Django open source ; pour les métriques de l’ensemble du système, Munin ; et pour la supervision des services externes, Pingdom et PagerDuty

[botplaysdice]

Au tout début, Instagram donnait l’impression de n’être qu’une appli de filtres d’image un peu tape-à-l’œil (à l’époque où ils s’obstinaient à ne supporter que l’iPhone). Je n’aurais jamais imaginé que ça deviendrait un tel carton. (Mon imagination n’allait pas jusque-là ;;;)

[princox]

Je me souviens qu’en comparant des produits ayant connu un exit, Instagram se distinguait par un montant d’exit par personne particulièrement élevé. Je pense qu’il y a beaucoup à en apprendre.

[GN⁺]

Avis Hacker News

• Un article sur la manière dont Instagram a atteint 14 millions d'utilisateurs avec seulement trois ingénieurs
• Un débat sur le langage, certains supposant qu'Instagram a été écrit en Objective-C et UIKit
• Certains commentaires saluent la simplicité de la stack technique d'Instagram et suggèrent que de nombreuses entreprises pourraient tirer profit d'une approche similaire
• L'importance du choix des membres de l'équipe est soulignée dans ce commentaire : « Si vous choisissez les bonnes personnes, vous n'avez besoin que de quelques-unes. Sinon, vous finissez par avoir besoin de tout le monde. »
• De la curiosité sur la manière dont Instagram mettait à jour instantanément les fils de millions d'utilisateurs, une tâche considérée comme plus difficile que la montée en charge des lectures dans les systèmes distribués
• Des spéculations sur le niveau de montée en charge qu'Instagram aurait pu atteindre avec les technologies modernes, en tenant compte de Django, Postgres, Redis et des progrès de la vitesse du matériel
• L'article relance la discussion sur la taille des équipes d'ingénierie, certaines personnes ayant du mal à comprendre pourquoi certaines organisations avec une simple application CRUD de base ont besoin de milliers d'ingénieurs
• Un sentiment d'inspiration chez certains lecteurs, qui expriment l'envie de créer leur propre version d'Instagram
• Il est mentionné qu'aux débuts d'Instagram, il n'y avait qu'un seul frontend, une application iOS, et moins de fonctionnalités que les plateformes de réseaux sociaux modernes
• Partage d'une expérience interne récente sur le développement de l'application Threads de Meta sur l'infrastructure d'Instagram, en soulignant le succès de l'application et la taille des équipes concernées