Instagram served 14 million users with three engineers on Django and Postgres. What does that tell you about how to choose an architecture for a new product?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can identify the binding constraint. For most products it is not traffic.
What Instagram actually did
Their 2011 post described Django, PostgreSQL, Redis, memcached and nginx on EC2 — nothing exotic — with stated principles of keeping it simple, not reinventing the wheel, and using proven technologies.
The moves in order: vertical scaling, then read replicas and aggressive memcached, then sharding only when required — using logical shards mapped to physical databases, with IDs encoding the shard, so moving a shard requires no rehashing. Photos went to S3 behind a CDN, which was the one place they spent.
The lesson for a new product
The constraint that dominates is engineering capacity, not traffic. Complexity consumes capacity continuously: every service, broker and cluster is operational load carried every week by a team that could have been building product. A three-person team running a microservice estate is a three-person team not shipping features.
Three rules follow:
Boring technology is a feature. Proven components have known failure modes, documentation, hiring pools and answers on the internet. Novel components spend your innovation budget on something the customer cannot see.
Do the simple thing until a measurement says otherwise. Not until it feels small — until a number says it is inadequate.
Spend your care on the irreversible decisions. Instagram got the data model, the ID scheme and the sharding structure right early, because those are one-way doors, and left everything else simple. That combination — careful where reversal is expensive, casual where it is cheap — is the whole skill.
The honest counterweight
This is not an argument that simplicity always wins. Instagram had a narrow product with a clean data model and a workload that partitions beautifully. A system with genuinely heterogeneous workloads, hard multi-region requirements or forty teams has different constraints, and applying Instagram's answer there would be its own kind of cargo cult.
What a strong answer adds
Turning it into a question to ask in any architecture review: "which requirement does this component satisfy, and what happens if we leave it out?" Anything without a crisp answer is speculative complexity — and speculative complexity is the kind that is never removed, because removing it is nobody's project.