Design Instagram - System Design Tutorial for Beginners

We will design a small photo-sharing service inspired by familiar social apps. Users publish photos, follow creators and view a feed. This is a teaching design, not a description of Instagram’s internal architecture.

Start with an assumed 100,000 daily active users, 10,000 new photos per day and 1,000,000 feed openings per day. Photos average an assumed 2 MB before derived sizes. These numbers define an exercise; real requirements and measured workloads may differ.

Include upload, follow, feed reading and deletion. Begin with chronological ordering; ranking and recommendations are separate capabilities. Decide whether accounts can be private and whether feed freshness may lag behind publication.

A successful publish response should mean the intended post and media are durably recorded under the chosen contract. A feed must not expose private content solely because a cached post identifier is present.

Estimate reads, uploads, stored media and transfer separately. At 10,000 uploads × 2 MB, raw uploads add about 20 GB per day in decimal units, before variants, replicas, indexes and backups.

The application can issue a short-lived upload permission for an allowed object and size. The client uploads to an object store; completion is verified before the post becomes available. An issued permission does not prove the file finished uploading.

Save identifiers, owner, media references, visibility and publication state as metadata. Workers can validate media and create smaller display variants. Define what happens when storage succeeds but metadata commit fails, or processing fails after upload.

A CDN can deliver suitable public variants; private media needs its own access and cache policy. Orphan uploads and deleted content need cleanup. A durable post record is not the same thing as a permanently valid public URL.

In push mode, each new post creates one derived feed entry per follower. In pull mode, the feed assembles candidates when read. Hybrid mode uses push for up to 1,000 followers and pull above that teaching threshold.

The calculator assumes 10 posts per day from this creator, 5,000 feed reads per day and 20 followed creators with 10 candidate posts each for pull reads. A prepared push feed uses one simplified indexed access per read. It counts illustrative work units, not database IO, ranking cost, latency or real social-app behaviour.

A user may unfollow a creator or a post may become private or be deleted. Derived feed entries and caches can lag behind those changes. Verify the authoritative visibility rule at the appropriate serving boundary, and propagate removals with a repair plan.

For public feed lists, bounded staleness may be acceptable. For private content, a stale copy can create a permission problem. Permission checks and media delivery must agree; hiding a post card while leaving an unrestricted media URL is not the full rule.

Track cursor-based pagination, duplicate entries and fan-out backlog. A timestamp alone may not uniquely order posts; use a stable ordering contract.

Object storage, a metadata database, a queue and a CDN are plausible building blocks, not mandatory product choices. S3 multipart upload documentation is one real upload option; PostgreSQL constraints can support suitable metadata rules. Sources checked 6 October 2026.

Push can make reads simpler while high-follower publication creates many updates. Pull avoids those copies but moves assembly cost to reads. Hybrid designs add routing and merge logic. Benchmark skewed follower counts and failure recovery, not only an average creator.

Monitor publication completion, feed latency, stale entries, privacy checks and media transfer cost. Start with one coherent implementation and add specialised components when evidence justifies them.

A derived feed can use ideas from CQRS, while required publication events can use Outbox. Publisher/Subscriber gives independent consumers their own processing progress; access enforcement still belongs to the content contract.

Store media and metadata according to their different roles. Choose feed fan-out from the workload, account for hot creators and make freshness visible.

Enforce visibility across feed and media paths. Measure completion, delivery cost and failure recovery before expanding the design.