Instagram Photo Sharing at Scale
How Instagram handles billions of photos: storage, processing, delivery, and scaling challenges.
What is a photo-sharing system?
A photo-sharing system accepts an image from a creator, preserves the original, makes device-appropriate derivatives, checks whether the post is allowed, and delivers it through profiles and personalized feeds. The large image bytes and the small feed records follow different paths, but both must agree on which media version is safe to show.
In plain language: a successful upload is not automatically a published photo. The platform first protects the original, prepares smaller copies, applies moderation, and then exposes a versioned post that followers can discover and load from a nearby CDN.
Core invariant
Never publish a media version until its original is durable, its required derivatives are addressable, and its moderation state permits delivery. Feed caches and CDN edges may converge later, but a versioned tombstone or authorization denial must prevent an old copy from becoming visible again.
This case study uses an illustrative planning envelope of 100M accepted photos per day, a 4 MB average original, six delivery derivatives, and a 3x peak multiplier. The estimates are design inputs, not claims about Instagram's current private infrastructure. Review message queues and CDN behavior first if asynchronous workers or edge caches are new.
The unit of work is a publishable media version
A post combines small metadata with large immutable objects. The upload API owns the creator's durable receipt; the publication service owns the transition from private processing state to an eligible version that feeds and caches may reference.
Functional requirements
- Let a creator resumably upload a photo and inspect
uploading,processing,review,published, orblockedstate. - Preserve the accepted original and generate device-appropriate thumbnails and display derivatives.
- Publish eligible posts to the creator profile and follower feeds with likes, comments, saves, reports, and deletes.
- Apply automated and human moderation before broad distribution, then propagate later policy decisions.
- Deliver a prepared derivative through a CDN without routing ordinary views through the upload service.
Non-functional requirements
- Acknowledge an upload only after the original and its checksum are durably recorded.
- Return profile and feed metadata within 300 ms P99 from supported regions; transfer image bytes separately from the CDN.
- Make publication retries idempotent so duplicate jobs cannot create duplicate derivatives, posts, or fan-out events.
- Keep the creator's state monotonic and readable after a successful transition, while follower feeds converge asynchronously.
- Degrade freshness or image quality before bypassing moderation, deletion, or authorization decisions.
Consistency promises
- Creator state is read-your-writes: after
publishedis returned, the creator's profile must show that version or a newer policy state. - Follower discovery is eventually consistent: fan-out workers and feed caches may take seconds to converge, and that delay is measured.
- Media objects are immutable: a correction creates a new derivative manifest and URL rather than overwriting bytes under a warm cache key.
- Removal is deny-first: authorization and post metadata reject a removed version immediately; CDN purge is an additional cleanup path, not the only protection.
Scope boundary
This design covers still-photo upload, derivatives, moderation, post publication, feed references, and CDN delivery. Video transcoding, Stories expiration, direct messages, ad auctions, and ranking-model training are separate systems.