1. The problem: why requirements come first

"Design Instagram" could mean a weekend photo-sharing app for 1,000 people or a planet-scale platform for two billion. Those two systems share a name and almost nothing else: the first runs on one server with one database; the second needs CDNs, sharded databases, event streams, caches, ML pipelines and multiple data centres. Every architectural decision depends on the requirements. Without them, you can't tell whether a design is good — only whether it's elaborate.

Requirements also protect you from the two classic failure modes:

• Under-engineering — a single PostgreSQL instance serving 300,000 feed reads per second. It will fall over.
• Over-engineering — globally replicated consensus databases for like counts that nobody needs to be exact. It works, but it is slow, costly and complex for no benefit.

In an interview the first five minutes are spent here (see How to Approach). In real companies this phase is a design document's "Goals / Non-goals" section, and it is where most expensive mistakes are either made or avoided.

2. Functional vs non-functional requirements

A useful trick: functional requirements are about one user's experience; non-functional requirements are about all users at once — at peak, during failures, over years.

3. Functional requirements for Instagram

3.1 The feature list with priorities

We classify each feature as Core (must design end-to-end), Extended (show where it plugs in; design in depth only if asked) or Out of scope (explicitly excluded — saying so is a sign of judgement, not laziness).

3.2 Write them as user stories with acceptance criteria

Turning features into precise statements exposes hidden requirements:

As a user, I can publish a post with 1–10 photos/videos and a caption.
  - Upload succeeds on flaky mobile networks (resumable, retry-safe).
  - The post shows on my profile immediately after I publish it (read-your-writes).
  - Followers see it in their feeds within ~seconds to a minute.
  - Videos may show "processing" for a short time; photos appear immediately.

As a user, I can open my home feed and scroll.
  - First page renders quickly; next pages load before I reach them (prefetch).
  - Ranked by relevance, mostly recent posts from accounts I follow.
  - Never shows posts from accounts that blocked me or that I can't access.

As a user, I can like a post.
  - Tapping like twice does not create two likes (idempotent).
  - The heart turns red instantly; the count may lag slightly.

Each acceptance criterion quietly introduces a non-functional requirement (resumability, read-your-writes, freshness, privacy, idempotency) — exactly the material for the next section.

3.3 Functional requirements that people forget

• Deletion and editing — deleting a post must remove it from feeds, caches, search and (eventually) storage and the CDN.
• Privacy controls — private accounts, blocking, muting, "close friends" Stories audiences.
• Pagination — every list (feed, comments, followers) is unbounded and must be paged.
• Multi-device — the same account on a phone, a tablet and the web; state must sync.
• Internationalisation — Unicode usernames and captions, right-to-left scripts, local time zones.

4. Non-functional requirements

These are the numbers that shape the architecture. In an interview, you propose them and the interviewer adjusts them. Below are the working assumptions used throughout this guide — they are assumptions for design purposes, not official Instagram statistics.

4.1 Scale assumptions

How these numbers are derived and what they imply for storage, bandwidth and servers is worked through in Back-of-the-Envelope Estimation.

4.2 Availability: 99.99% and what it really means

Availability is the fraction of time (or of requests) for which the system works correctly. It is usually expressed in "nines":

For Instagram we target 99.99% for the core read path (feed, profiles, media) and for uploads. Four minutes per month is far less than the time it takes a human to be paged, log in and diagnose a problem — so four nines cannot be achieved by humans fixing things. It requires automatic failover, redundancy in every layer, gradual rollouts with automatic rollback, and graceful degradation. Extended features such as search or Explore can reasonably target 99.9%: if search is briefly down, the app is still usable.

Two practical refinements:

• Request-based availability is more useful than time-based at this scale: availability = successful requests / valid requests. A 1% error rate for an hour is a partial outage, not "up" or "down".
• Graceful degradation counts. If ranking is down and we serve a chronological feed, the request succeeded — the user saw a feed. Define "success" carefully.

The maths of how component availabilities combine (series vs parallel) is in Core Principles.

4.3 Latency targets

Latency is the time from request to response. We specify it with percentiles, not averages: "p99 = 300 ms" means 99% of requests finish within 300 ms. Averages hide the slow tail that real users feel — a user who loads 20 feed pages per day will hit the p95 experience about once a day. (Percentiles are explained in depth in Core Principles.)

4.4 Durability of media and data

Durability is the probability that data, once acknowledged as stored, is never lost. It is different from availability: a photo can be temporarily unavailable (a region is down) but must never be permanently lost.

• Media: target object-storage-class durability (S3 is designed for 99.999999999% — "11 nines" — annual object durability). Achieved by replicating or erasure-coding each object across multiple disks, racks and availability zones, plus cross-region copies for disaster recovery. See Object Storage.
• Acknowledged writes: once the app says "posted", the post must survive any single machine or zone failure. That means the metadata write is replicated (e.g. Cassandra with replication factor 3 and a quorum write) before success is returned — an RPO (recovery point objective: how much data you can lose) of zero for posts.
• Derived data is re-buildable: timelines in Redis, search indexes and counters can be regenerated from the source of truth, so they need availability more than durability.
• Deletes must also be durable: when a user deletes content, it must not resurface from a replica or backup restore.

4.5 Consistency expectations per feature

Consistency here means: after a write, what can readers see? Strong consistency (everyone sees the latest write immediately) costs latency and availability, so we pay for it only where users would notice or be harmed. Full theory in CAP, PACELC & Consistency Models.

4.6 Read:write ratio

Instagram is read-heavy, but the ratio depends on what you count:

• Content views vs content creation: each post is created once and viewed hundreds of times → ~100:1 or more. This is the ratio that justifies pre-computed feeds, caches and CDNs.
• Bytes out vs bytes in: media egress (tens of PB/day) vs uploads (hundreds of TB/day) → also ~100:1.
• API requests: likes are writes and very frequent, so at the API level the ratio is lower (perhaps ~3–5:1). That's why the like path is designed as a write-optimised path (append-only store, sharded counters) even inside a read-heavy product.

Saying "read-heavy, ~100:1, so I'll optimise reads — but likes are a high-volume write path that needs special handling" is a strong, nuanced interview statement.

4.7 Security & privacy

• Authentication & authorization on every request at the API Gateway; tokens with expiry; per-object access checks (private accounts, blocks). See Authentication.
• Encryption in transit (TLS everywhere, including service-to-service) and at rest (disk/object encryption, managed keys).
• Media access control: signed, expiring CDN URLs so private photos can't be hot-linked forever (see CDN).
• Abuse prevention: rate limiting, spam and bot detection, content moderation in the media pipeline.
• Regulation: data deletion and export (e.g. GDPR "right to erasure"), data residency where required, minors' protections, audit logs.

Details in Security & Privacy.

4.8 Cost

At this scale, cost is a first-class requirement. A design that is 20% cheaper per user saves enormous amounts annually. The big cost drivers are media storage (PBs per year, growing forever), egress bandwidth (CDN), RAM for caches, and compute for transcoding and ML. Cost-shaped decisions include storage tiering (move old, rarely-viewed media to cheaper cold storage), efficient codecs (WebP/AVIF images, modern video codecs), not fanning out to inactive users, and right-sizing caches with the 80/20 rule.

4.9 Other quality attributes

5. Making requirements measurable: SLIs, SLOs and SLAs

"Fast" and "reliable" are not testable. Site Reliability Engineering (SRE) practice turns non-functional requirements into three precise terms:

5.1 Example SLOs for Instagram

6. From requirement to design decision to component

This is the most important table in the lesson. Every box in the Instagram diagram exists because of a requirement — if you can't say which one, the box probably shouldn't be there.

 REQUIREMENT                   DECISION                        COMPONENT
 ─────────────                 ─────────                       ─────────
 "feed p99 < 300 ms"  ───────> precompute timelines ────────> Fan-out workers ─> Redis
 "~100:1 read-heavy"  ───────> cache + replicas + CDN ──────> Redis, read replicas, CDN
 "never lose a photo" ───────> replicate across zones ──────> Object storage (S3)
 "unique usernames"   ───────> single-leader + UNIQUE ──────> PostgreSQL (sharded)
 "counts can lag"     ───────> async, eventual counters ────> Kafka ─> Redis counters

7. Clarifying questions to ask the interviewer

Below are the questions worth asking for "Design Instagram", with typical interviewer answers and what you do with them. You won't ask all of them — pick the 6–8 that most change the design, and propose an answer in the same breath ("I'll assume X — OK?").

8. How requirements change the design

The best way to understand requirements is to see what happens when one changes. Interviewers love this as a follow-up ("what if…?").

9. How Instagram uses requirements to shape its design

Reading the Instagram diagram through the lens of requirements:

• The API path and the media path are separate because the latency and bandwidth requirements of the two are completely different — JSON responses are small and personalised (served by services), media is huge and shared (served by the CDN).
• Kafka sits in the middle because many requirements are "eventually, within seconds" (fan-out, search indexing, notifications, analytics) rather than "before the response". Doing them asynchronously keeps the upload latency target and isolates failures.
• Different stores for different consistency needs: PostgreSQL where uniqueness and transactions matter (users), Cassandra where write throughput and availability matter (posts, likes), Redis where latency matters (timelines, counters).
• Stateless services exist because of the availability and scalability requirements: any instance can die or be added without losing data.

A worked requirements summary (what you'd leave on the whiteboard)

INSTAGRAM — REQUIREMENTS (agreed with interviewer)

Functional (core):    post photo/video/carousel · home feed (ranked) · follow/unfollow
                      like/comment · profiles · auth
Functional (extended): stories (24h) · search · DMs · notifications · explore
Out of scope:         ads · shopping · payments · live

Scale:        2B MAU · 500M DAU · 100M posts/day · 10B feed loads/day · 5B likes/day
Latency:      feed p99 < 300 ms (server) · like ack p99 < 200 ms · post visible to followers < 1 min
Availability: 99.99% feed/upload/media · 99.9% search/explore
Durability:   no acknowledged post/media ever lost (11 nines media)
Consistency:  strong → usernames, auth, privacy · ordered → DMs
              read-your-writes → own posts · eventual → feed, counts, search
Read:write:   ~100:1 content views : uploads (likes = heavy write path)
Security:     authN/Z on every request, TLS, signed media URLs, privacy, deletion
Cost:         storage tiering, efficient codecs, skip inactive users in fan-out

10. Trade-offs & common pitfalls

Common pitfalls

• Skipping non-functional requirements. Listing features only, then having no basis for choosing caches, replicas or consistency models.
• "Highly available and strongly consistent everywhere." During a network partition you can't have both (CAP); pick per feature.
• Averages instead of percentiles. "Average latency 100 ms" says nothing about the 1% of users waiting 3 seconds.
• Confusing availability with durability. A system can be up and still have lost data, or down with all data safe.
• Forgetting deletes and privacy. Blocked users, private accounts and legal deletion touch every read path and every cache.
• Scope creep. Trying to cover DMs, Reels, Explore and ads in 45 minutes. Say "out of scope" explicitly.
• Treating assumptions as facts. Say "assume 500M DAU", not "Instagram has exactly 500M DAU".
• Setting a 100% target. Leaves no error budget and is physically impossible.

11. Real-world technologies

12. Interview corner

13. Check your understanding

Related lessons

• How to Approach a System Design Problem — where requirements fit in the 6-step framework
• Back-of-the-Envelope Estimation — turning the scale assumptions into QPS, storage and bandwidth
• Core Principles — availability maths, percentiles, scalability
• CAP, PACELC & Consistency Models — the theory behind per-feature consistency choices
• News Feed — how the latency and freshness requirements are met
• Observability — measuring SLIs and alerting on SLOs
• Security & Privacy — the security and privacy requirements in depth