Section 7: Where the Bike Could Get Lost - Deep Dive (Candidate-Driven)

Executive Summary: The territory you pick is itself scored. We go deep on three load-bearing places: the photo pipeline that moves 10 million images a day without touching the API tier, the path that makes Maya's bike searchable in under a minute without regressing the index, and masked messaging that lets Daniel reach Maya without exposing either phone number. Each dive runs mechanism, number, trade-off, then pushback.

The interviewer sets the marker down: "You've got the boxes. Where do you want to go deeper?" Your answer shows what you think would break, so answer with a plan:

"Search and trust and safety are the two hardest subsystems, and I'd give each its own pass next. First, three quietly load-bearing places: photos, at 20 TB a day; the commit-to-searchable path, where the freshness SLO lives; and messaging, where buyers meet sellers and scammers find them."

You've just booked the search and trust-and-safety deep dives, and said why these three come first.

Dive One: The Photo Pipeline - Bytes That Never Touch the API

Maya picks six photos of the Trek; the client resizes each to ≤2,048 px, about 1.5 MB. Platform-wide that's 10 million photos a day, 580 uploads/s at the Sunday peak, and **7 Gbps of peak ingress**.

• The presigned URL is narrow: signed for one object key, one content type and the exact declared Content-Length, reusable for 15 minutes so retries work. It points at a private uploads/ quarantine bucket with no CDN origin and a 24-hour expiry. A leaked URL can fill one slot, briefly.
• The processor strips metadata: it applies the EXIF orientation to the pixels, then writes fresh WebP files with metadata explicitly stripped (common libraries copy it through a re-encode unless told not to). A test asserts no GPS tag survives: a driveway photo's GPS would reveal the address the ~1 km fuzzing hides.
• Three variants (thumb 25 KB, card 100 KB, full 350 KB): ~2 MB stored per photo with the stripped full-resolution original.
• A perceptual hash and classifier score feed Section 9's moderation.
• Photo state moves uploaded → processed → approved; listings show only approved photos.

Keys (photos/{photo_id}/{variant}.webp) are immutable: a swapped photo gets a new photo_id, so edits never need invalidation and long CDN TTLs absorb 270K image requests/s at peak against a 90% hit target. Takedowns and deletions are the exception: they delete the origin objects and issue an explicit CDN purge for those keys. A daily sweep batch-deletes photos of listings closed more than 90 days ago; a lifecycle rule, which counts age from creation, backstops anything older than ~1 year. That turns an unbounded 7.3 PB/year into **2.2 PB steady state**.

The Pushback: "What if a client uploads malware, or a 200 MB file?"

"The 200 MB file never lands: the exact length is in the signature, so the object store rejects any other size, and the processor re-checks anyway. For hostile content I ignore the declared type, check magic bytes, cap pixel count before decoding so a decompression bomb can't exhaust memory, and decode in a network-less sandbox. Only re-encoded pixels survive, so payloads hidden in headers or metadata don't make it out. Anything that fails to decode is rejected and deleted."

Quick check before moving on: