Design the backend for a photo-sharing service where people upload images from their phones and browse a scrolling feed of photos from accounts they follow (think a popular mobile photo app). Every original upload must be turned into several downscaled renditions, and the feed has to render thumbnails fast on flaky mobile networks.

Operating context. Roughly 40 million daily active users. Uploads run about 3,000 photos/sec at steady state, tripling during evening peaks; the average original is 4 MB. Feed and profile browsing is far heavier: on the order of 300,000 image fetches/sec globally, and the vast majority of those are small thumbnails, not full-resolution originals. Users are spread across many regions and expect a thumbnail to start painting in well under 200 ms. An upload may finish processing a few seconds after the client's request returns, but it must eventually appear in followers' feeds.

Out of scope. Video, live streaming, the recommendation/ranking model behind the feed, content-moderation ML, direct messaging, and the mobile client UI. Assume separate teams own those. You may treat the follow-graph and per-user feed materialization as an existing service you call — but be explicit about the contract you rely on.

What to produce. A high-level architecture covering: the upload path (how bytes get from client to durable storage and how the processing job is triggered), the image-processing pipeline that produces multiple renditions, where originals and renditions live and how they are served through a CDN, the metadata store and its partitioning, how a finished upload is integrated into followers' feeds, and how the thumbnail read path stays fast and cheap under the read skew. Sketch the major components and the request/data flow between them; we will probe specifics at each checkpoint.