sydepsystem design atlas

Photo Sharing (Instagram-style)

Upload, process into multiple sizes, and serve via CDN.

IntermediateSocialMedia
ClientClientAPI GatewayNetworkingUpload ServiceComputeRaw Photo StorageStorageProcessing QueueMessagingImage ProcessorComputeVariant StorageStorageFeed ServiceComputeFeed StoreStorageCDNNetworking

Uploaded photos are stored in object storage and processed asynchronously into thumbnail/preview/full-size variants, while metadata and the feed graph live in separate stores tuned for each access pattern.

When to use it

  • Media-heavy content needs multiple resolutions for different surfaces (thumbnail, feed, full view)
  • Upload and processing should not block the user waiting for a response

Trade-offs

  • Image processing latency means the newest post's variants may lag briefly behind the original
  • Storing every resolution multiplies storage cost versus generating on demand

Components used

Mobile AppAPI GatewayManaged App ServiceObject StorageMessage QueueBatch / Scheduled JobDocument DatabaseCDN

How it works

  • Uploads go directly to object storage, then an asynchronous pipeline generates the derivative sizes and formats each surface needs.
  • Metadata lives in a database while binaries live in storage, and the CDN serves every read.
  • Derivatives are generated once and cached forever, since the original never changes.

Used in the wild

  • Social photo feeds.
  • Product image pipelines for commerce catalogues.
  • User avatar and media handling in any application.

Good to know

  • Strip EXIF metadata on upload. Photos routinely embed GPS coordinates, and publishing them unmodified has repeatedly exposed people's home addresses.
  • Generating derivatives on demand at first request, then caching, usually beats pre-generating every size — most uploads are never viewed at most sizes.