Social & feeds
Media feed - the feed serves URLs, the edge serves bytes
direct upload, rendition pipeline, and who actually pays for the pixels
What this board gets wrong on purpose
The tension
The post is published synchronously and the renditions are made asynchronously, so there is a window - usually two seconds, occasionally twenty minutes when the queue backs up - in which a post exists and its thumbnails do not. The client falls back to the 2.5 MB original over cellular, which is the worst possible outcome on the worst possible connection, and nothing on this board measures how often it happens. The second half is the CDN: renditions are immutable and cached for a year, so a deletion or a takedown propagates only as fast as a purge API nobody has load tested, and the signed URL expiry is the only real revocation - which means the honest takedown latency is the token lifetime, six hours, not the moment somebody pressed delete.
Requirements
Clarifying questions to ask first
- Do we keep the original file forever, or only the renditions? This is the single biggest cost lever on the whole system and it is a product decision, not an engineering one.
- Are images public or access-controlled? Public means long-lived immutable URLs and a CDN that needs no identity. Controlled means signed URLs, which means an expiry, which means a cache key that churns.
- Which renditions does the client actually use, and who decides - server or device? A device that asks for arbitrary widths makes the cache useless.
- What is the acceptable publish-to-visible lag? If it must be zero, the transcode cannot be asynchronous and the whole board changes.
- Video too, or photos only? Video is a different pipeline with segmenting, multiple bitrates and a manifest. This board is photos.
- What is the egress budget? See the capacity page - it dominates every other cost by an order of magnitude.
Functional
- Upload a photo and publish a post referencing it.
- Read a feed: a page of recent posts from accounts you follow, each with a displayable image URL.
- Serve each image at the size the device needs, at the edge, worldwide.
- Delete a post; the image must stop being served.
Non-functional
- Feed API p99 under 150 ms. It returns a few kilobytes of JSON; there is no excuse for it to be slow.
- Image time-to-first-byte p95 under 100 ms from the edge, with a 95%+ CDN hit rate.
- Publish-to-renditions-ready p95 under 10 seconds.
- 99.99% durability target on originals, 99.9% availability on the read path.
- Upload must survive a flaky mobile connection: resumable, idempotent, retryable.
Explicitly out of scope
Ranking, stories, video, ads, comments, and the recommendation model. The feed order is drawn as one box.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 8-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 8walkthrough steps
- 5tables28 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Timelines, follows, fan-out - the read-heavy classics.