Instagram ने सिर्फ 3 engineers के साथ 1.4 करोड़ users कैसे हासिल किए

• 2010/10 से 2011/11 तक लगभग 1 साल में 0 से 1.4 करोड़ users तक पहुँचा। engineers सिर्फ 3 थे
• 3 सिद्धांतों का पालन किया गया
  • चीज़ों को बहुत सरल रखना (Keep things very simple.)
  • पहिए को फिर से आविष्कार न करना (Don’t re-invent the wheel.)
  • जहाँ संभव हो, प्रमाणित और मज़बूत technologies का उपयोग करना (Use proven, solid technologies when possible.)

user के नज़रिए से stack पर एक सरल नज़र

• शुरुआती infrastructure AWS EC2 पर Ubuntu Linux था
• Instagram app पहले सिर्फ iOS पर आया, और Swift की घोषणा से पहले था, इसलिए संभवतः Objective-C + UIKit रहा होगा
• load balancing के लिए Amazon का Elastic Load Balancer और 3 NGINX instances का उपयोग किया गया
• backend
  • application server Python में बनाया गया था, इसलिए Django और WSGI server के रूप में Gunicorn इस्तेमाल हुआ
  • Fabric का उपयोग करके कई instances पर एक ही command एक साथ चलाई जाती थी। इससे code कुछ ही seconds में deploy हो जाता था
  • 25 high-performance CPU Extra-Large machines चल रही थीं। सभी Stateless थीं, इसलिए ज़रूरत पड़ने पर आसानी से और जोड़ी जा सकती थीं
• सामान्य data store
  • संबंधित photo ID, उस ID की वास्तविक photo, और photo के लिए user data
  • application server PostgreSQL से data लाता था
  • Django और PostgreSQL के बीच pgbouncer से pooling की जाती थी
  • Instagram समय के अनुसार sort किए जा सकने वाले ID का उपयोग करता था: 41-bit milliseconds + 13-bit shard ID + 10-bit auto-increment sequence
• photo storage: S3 और Cloudfront
• caching: Redis और Memcached
  • smart hashing के जरिए 30 करोड़ key mappings को 5GB से कम space में store किया गया
  • और 2 साल बाद Facebook ने Memcached को scale करके प्रति second अरबों requests तक विस्तार करने के तरीके पर एक paper प्रकाशित किया
• Postgres और Redis दोनों Master-Replica mode में चल रहे थे। Amazon EBS snapshots से लगातार backup लिया जाता था
• Push Notification और Async Task: notifications के लिए pyapns, और task queue के लिए Gearman
• errors को real time में monitor करने के लिए open source Django app Sentry का उपयोग किया गया, पूरे system metrics के लिए Munin, और external service monitoring के लिए Pingdom और PagerDuty का उपयोग किया गया

[botplaysdice]

Instagram शुरुआती दिनों में (जब वह ज़िद करके सिर्फ iPhone को ही support करता था) बस एक fancy image filter app जैसा लगता था। लेकिन यह इतना बड़ा hit होगा, इसकी मैंने बिल्कुल भी कल्पना नहीं की थी। (मेरी कल्पनाशक्ति बस उतनी ही थी;;;)

[princox]

Exit तक पहुँचे products की तुलना करते समय, मुझे याद है कि Instagram में प्रति व्यक्ति exit amount काफ़ी ऊँचा था। मेरा मानना है कि इससे सीखने लायक बहुत कुछ है।

[GN⁺]

Hacker News की राय

• यह लेख इस बारे में है कि Instagram ने सिर्फ़ तीन इंजीनियरों के साथ 1.4 करोड़ उपयोगकर्ता कैसे हासिल किए
• इस बात पर बहस कि Instagram के Objective-C और UIKit में लिखा होने की धारणा किस हद तक सही है
• कुछ टिप्पणियाँ Instagram के tech stack की सादगी की प्रशंसा करती हैं और सुझाव देती हैं कि कई कंपनियाँ इसी तरह के दृष्टिकोण से लाभ उठा सकती हैं
• एक टिप्पणी में टीम सदस्यों के चयन के महत्व पर ज़ोर दिया गया: "अगर आप सही लोगों को चुनते हैं, तो आपको केवल कुछ ही लोगों की ज़रूरत होती है। नहीं तो आपको सबकी ज़रूरत पड़ती है।"
• इस बात को लेकर जिज्ञासा कि Instagram लाखों उपयोगकर्ताओं की feeds को तुरंत कैसे अपडेट करता था, जिसे distributed systems में reads को scale करने से भी अधिक चुनौतीपूर्ण काम माना गया
• इस पर अटकलें कि Django, Postgres, Redis और hardware speed में हुई प्रगति को देखते हुए Instagram आधुनिक तकनीक के साथ कितना scale कर सकता था
• यह लेख इंजीनियरिंग टीम के आकार पर चर्चा को उकसाता है, और कुछ लोगों के लिए यह समझना कठिन है कि केवल बुनियादी CRUD app रखने वाले कुछ संगठनों को हज़ारों इंजीनियरों की ज़रूरत क्यों पड़ती है
• कुछ पाठकों के बीच प्रेरणा की भावना, जो Instagram का अपना संस्करण बनाना चाहते हैं
• यह उल्लेख कि Instagram के शुरुआती दिनों में केवल एक ही frontend था, यानी iOS app, और उसमें आधुनिक social media platforms की तुलना में कम features थे
• Instagram के infrastructure पर Meta के Threads app को विकसित करने का हालिया अंदरूनी अनुभव साझा किया गया, जिसमें app की सफलता और संबंधित टीमों के आकार पर ज़ोर दिया गया