Sharding at Instagram: Case Study
Issue #108: System Design Interview Roadmap • Section 4: Scalability
When 400 Million Photos Per Day Break Your Database
Instagram's growth story reads like a distributed systems nightmare turned triumph. In 2012, they were drowning in their own success—400 million photos uploaded daily were crushing their PostgreSQL database. Traditional scaling approaches hit walls hard. Read replicas couldn't handle write-heavy workloads, and vertical scaling reached physical limits. The solution? A sharding strategy so elegant that it became the blueprint for social media platforms worldwide.
What You'll Master Today
Understanding Instagram's sharding evolution will teach you three critical skills: designing partition keys that prevent hotspots, implementing consistent hashing for seamless scaling, and handling cross-shard queries without sacrificing performance. These patterns apply directly to any application dealing with user-generated content at scale.
Instagram's Three-Phase Sharding Evolution
Phase 1: The Monolithic Collapse (2010-2012)
Instagram started with a single PostgreSQL instance serving everything. When celebrity posts created traffic spikes, the entire platform buckled. Users couldn't upload photos, feeds wouldn't load, and the engineering team faced constant firefighting. The database became both the heart and the bottleneck.
The wake-up call came during a viral moment when 2 million photos were uploaded in one hour. The database CPU hit 100%, and response times stretched to 30+ seconds. Traditional solutions like read replicas only postponed the inevitable—writes still funneled through one overwhelmed master.