Design a photo-sharing service

01An upload becomes a photo, then a feed candidate

Maya uploads a sunrise photo. The service should preserve the original, prepare a small preview, show the photo on Maya's profile and eventually include it in eligible followers' feeds. Those are related but separate results. Accepting bytes does not mean every image variant exists, and placing a photo ID in a feed does not grant permission to view it.

Support uploads, deletion, author galleries, following, private accounts, title search and a twenty-item home feed. Begin with chronological ordering; sophisticated recommendations and exact engagement counts are extensions. A private account requires approved followers. Define whether an already issued media link can remain usable briefly after access changes; a cached image cannot revoke bytes already downloaded.

A photo becomes published only when the variants required by its page exist. The uploader can see processing or failure while preparation continues. Feeds and search may lag publication, but they must not expose private or deleted content simply because an old candidate remains in an index. These decisions give us a small set of observable states before we choose queues or a CDN.

Before choosing storage or fanout, clarify whether the feed is chronological, how quickly an accepted photo must become ready and visible, and whether private-media access must be checked on every new request. The requirements below select that last policy rather than long-lived public image URLs.

02Functional requirements

Agree on these supported actions before selecting components.

1. Upload and publish photos. Authenticated authors upload an original, observe processing status and publish a photo only after its required preview and display variants exist.

2. Browse and discover. Provide author galleries, title search and a chronological home feed of up to twenty eligible followed-author photos.

3. Manage audience and deletion. Support follows and approval for private accounts. Owners delete photos; current access rules govern feed results and media delivery.

4. Recover interrupted work. Repeated upload completion and processing attempts preserve one photo identity and one accepted variant manifest.

03Non-functional requirements

Use these as illustrative interview assumptions to agree with the interviewer. Numerical targets require measurement; they are not claims about an existing product or a proven implementation. p95 (the 95th percentile) means 95% of measured operations finish within the stated time.

1. Workload. Use two million uploads/day and ten million feed opens/day: approximately 116 uploads/s and 579 feed requests/s at the fivefold peak. Preview delivery is approximately 10 TB/day; a fifty-million-follower author is a separate skew case.

2. Feed response time. Target regional p95 feed-metadata latency of 200 ms at the planning peak under normal operation. Image download and decoding are measured separately; this target is not a whole-screen rendering promise.

3. Readiness and freshness. For valid admitted images under the tested size and format limits, target p95 upload-complete-to-READY within 30 seconds. Target p95 propagation from READY to the prepared candidate list or author history used by an eligible active follower’s refresh within five seconds during normal processing. This makes the photo available for retrieval; the bounded twenty-item page need not display every new photo.

4. Durability. Accepted originals, published manifests and required variants must survive a worker restart or one storage-node failure within the region. A success status cannot depend on an encoder keeping its private local files.

5. Privacy. Check current audience permission before returning private photo metadata or admitting a new private-media transfer, including cache hits. Previously downloaded bytes and already admitted transfers are outside recall.

6. Isolation of expensive work. Bound upload bytes, decoded pixels, processing concurrency and follower batches. Large or malformed images and celebrity fanout must not exhaust ordinary feed-serving capacity.

04Trace one photo from upload to a follower

For a small service, use one application and a database holding photo metadata, follows and image bytes. The application receives the upload, validates its format and dimensions, produces a preview and a larger display image, then commits those bytes and metadata together. Return the photo identity after commit. If decoding fails, no published photo appears.

When follower Leo opens the feed, read the authors Leo follows, obtain a bounded recent set of their photos, check current visibility and sort by creation time with photo ID as a tie-breaker. Return twenty metadata records and the routes for their previews. The browser subsequently requests those image bytes. The author's gallery is simpler: query one owner's photos in order.

This baseline is intentionally small. It explains publication, feed assembly and media retrieval without making asynchronous jobs necessary for correctness. Its limits are easy to identify: image processing delays uploads, large bytes burden database backups and delivery, and each feed request repeats work across many authors. These limits motivate background processing, separate image storage and precomputed feed candidates.

05Size image delivery separately from feed requests

Assume two million uploads/day, 200 KB average originals, one million daily active readers and ten feed opens per reader. Each page contains twenty 50 KB previews. That gives about 23 uploads/s and 116 feed requests/s on average; a fivefold peak is approximately 116 uploads/s and 579 feed requests/s.

A feed API returning IDs is not delivering all those preview bytes itself. A content delivery network, or CDN, can serve repeated immutable images near readers. At a measured 90% byte-hit rate, preview traffic reaching the origin would fall toward 1 TB/day, although viewers still receive 10 TB/day.

Average follower counts can conceal one celebrity. Fifty million follower references for a single photo are qualitatively different from three hundred. Estimate that separate case before choosing to write every publication into every feed.

06Separate upload acceptance from publication

Create an upload before transferring or publishing its bytes.

Start-upload request

POST /photo-uploads

Response identities for the running example

Photo:  p900
Upload: up900

A retry returns those same identities. Small deployments may carry bytes through the application; larger deployments can give the client a narrowly scoped direct-upload target.

Completion authenticates the owner and verifies the stored object; an upload URL alone cannot publish a photo. Return pending rather than claiming all previews already exist. A feed cursor carries its viewer and continuation context, so it cannot be reused for another person's private feed.

Title search can initially use a database text index. A later search service returns candidate photo IDs; the serving path still checks their current visibility. Search freshness and access permission are different contracts.

07Choose records around three access patterns

Photo metadata, upload state and feed references serve different purposes.

The photo page reads by ID. The gallery reads by (ownerId, createdAt, photoId). Publication fanout reads followers of an author, while feed assembly reads authors followed by a viewer. Those opposite relationship lookups need suitable indexes; a single primary-key lookup does not answer them all efficiently.

After moving bytes to object storage, a manifest records exactly which immutable original and variants belong to a published photo. It is a small metadata document, not the images themselves. Keep originals private and preserve their exact accepted identity. A path containing a photo ID does not automatically prevent later overwrites; use create-only writes or a pinned object version.

A durable outbox row records processing or publication work in the same transaction as the photo-state change. A worker later relays it. This closes the gap where metadata commits but a separate queue send fails, leaving a photo permanently stuck.

08Let slow image work continue without blocking the uploader

Move original bytes to object storage when their volume and backup cost justify the split. Reserve the upload, receive and verify the original, then commit PROCESSING together with a processing event. The owner sees that the original was accepted while the application remains free to serve other requests.

The image worker then performs these steps:

1. Read the accepted original and decode it under pixel and memory limits.
2. Create the preview and large variant.
3. Write the outputs under immutable attempt-specific names and verify them.
4. Ask metadata storage to publish their manifest.

Only a successful READY transition makes the photo eligible for feeds.

The queue may redeliver a job after a timeout. Repeating image work is acceptable; replacing a newer published result with a stale worker's output is not. The publication update must check that this worker still owns the active processing attempt and that the photo was not deleted. A repeated successful completion returns the accepted manifest. Unreferenced attempt outputs can be cleaned up once no valid attempt can publish them.

This adds jobs, storage operations and recovery work. Synchronous processing is still simpler when small bounded images reliably fit the response budget. The advantage of the queue is predictable request handling and resumable work, not automatic exactly-once execution.

09Trade repeated feed reads for recipient writes

The baseline gathers photos when the viewer reads. If Leo follows 500 authors and we inspect 100 photos per author, we consider 50,000 rows to return twenty. Repeating that work on every feed open can cost more than preparing a small list in advance.

For ordinary authors, a publication worker inserts the new photo ID into active followers' candidate lists. This is fanout on write: one publication creates many recipient references. Enforce uniqueness on (viewerId, photoId) so replaying a job does not create duplicate feed slots. Store progress between follower batches so a crash can resume without loading an enormous follower list at once.

For very popular authors, keep an author timeline and merge its recent photos during reads. This avoids millions of writes for followers who may never open the app. A hybrid feed combines prepared ordinary-author candidates with those popular-author timelines, deduplicates IDs, checks current eligibility and returns a bounded page. Choose the threshold from posting rate, active readership and measured read/write cost, not a universal follower number.

Current privacy checks remain necessary in both paths. Leo can unfollow Maya while a delayed worker still inserts p900. The stale reference may remain temporarily, but it must not authorize a private photo. Candidate preparation answers what to consider; access checks answer what may be returned.

10Keep metadata decisions apart from media transfer

Place a CDN in front of immutable variants so a popular image can be served by many delivery locations. A feed request returns small metadata and approved media references; the image request retrieves bytes through the media path. Measure time to first preview independently of feed API latency.

For private photos, choose an authenticated media edge that checks the viewer's current access before serving bytes, including cache hits. This keeps authorization in front of delivery. A short-lived signed download grant is an alternative if access may remain valid until expiry; this design instead checks current permission. Do not call a URL viewer-bound unless the edge checks that viewer's session. Already downloaded bytes, and transfers admitted before a later revocation, cannot be recalled.

Replicate metadata according to the accepted-write durability requirement and protect originals through object-storage replication and backups. As metadata grows, distribute photo records while preserving author-gallery and viewer-feed indexes. Hashing photo IDs can spread stored rows but makes neither a gallery nor a feed local by itself.

Keep upload and feed-serving concurrency separately bounded. Slow large uploads should not occupy every worker needed for small feed reads. A ranking timeout may justify falling back to chronological order; a permission failure cannot justify serving unchecked private content.

For the chosen failure boundary, require durable majority commits across three metadata replicas in independent regional failure domains and object writes that survive one storage-node loss. Acknowledge original acceptance and publish manifests only after the relevant storage policy is satisfied. Measure queue capacity against the 30-second readiness and five-second feed-freshness targets.

11Test a crashed processor and delayed feed work

Worker W1 starts processing p900 and pauses after writing one preview. Another valid attempt completes the required set and publishes its manifest. W1 later resumes. Its publication must be rejected because its attempt is no longer current. Its independently named files cannot overwrite the accepted outputs. The owner sees one ready photo; unused files become cleanup work.

A feed worker inserts p900 for half a follower batch and crashes before saving progress. On retry it repeats that batch. Unique recipient/photo entries make the repeat harmless; checkpointing before completing the writes would instead miss recipients. Feed lag is visible in freshness metrics, while the authoritative published photo remains available on its page.

If the cache disappears, cap object-store requests and share one cache refill among concurrent requests for the same image so a popular image does not overload the object store. If metadata is unavailable, the media edge cannot establish current access and stops admitting new private transfers. Already delivered bytes cannot be recalled; a transfer admitted before a later revocation may finish.

Delete the metadata's published state first, then asynchronously remove feed references, search entries and obsolete media. Reads must still filter stale references. Physical deletion is background work, but the access decision cannot depend on every derived index having completed cleanup.

12Measure readiness, feed work and delivery cost

Monitor upload-to-ready delay, permanently failed decoding, processing backlog and missing manifest objects. For feeds, measure candidates examined per returned item, publication-to-feed lag, duplicate IDs and popular-author merge cost. For delivery, measure byte-hit ratio and origin traffic; a high request-hit ratio can hide expensive large-image misses.

Treat uploaded media as untrusted input. Bound encoded bytes, decoded pixel dimensions, CPU and memory. Restrict upload targets to the correct owner and object, and remove unnecessary location metadata according to product policy. Private media tokens and image contents should not appear in ordinary logs.

Storage cost includes originals, variants and retained failed-attempt outputs. Delivery cost includes CDN egress even when origin reads decrease. Feed preparation has its own write and memory cost: at 32 bytes per reference, 300 recipients use 9.6 KB per photo, whereas fifty million recipients use 1.6 GB before indexes and copies.

Test malformed images, response loss after upload acceptance, repeated processing, a deleted photo in a cached feed and a popular upload during cache loss. These tests examine the actual boundaries rather than whether each box on the architecture diagram is running.

13Check the design against the requirements

Use the agreed lists to check the finished design. The tests below still need to establish the targets; a proposed mechanism is not a measured result. FR refers to the numbered functional requirements above; NFR refers to the numbered non-functional requirements.

14Rapid revision

Remember: An uploaded original can survive while its preview fails. Publish only a verified, complete variant set.

In the interview, trace p900 from accepted original to READY manifest and then into Leo's feed. Use preview egress to justify delivery caches and follower amplification to justify the hybrid. End by showing how a stale worker and a stale feed reference are prevented from changing publication or access. Personalized recommendations can be added after those responsibilities are clear.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.