Sleetgarden: from one upload to three thumbnails

100%

Upload: get the bytes in safely

The user taps "Share". All the app needs back is a photo ID, so it doesn't wait for scanning or resizing.

1The app sends POST /photos (multipart, at most 25 MB) with the user's session token.
2The API streams the bytes to quarantine/{photoId}. Nothing in quarantine is ever publicly readable.
3The API inserts the photo row with status = scanning.
4The database confirms the row.
5The API returns 202 Accepted with the photoId. The app shows the local preview and polls GET /photos/{id} (the same path as steps 1 and 5) until the status changes.

Virus scan: the security gate

No other part of the system touches a file until the scanner has passed it.

S1The API sends a scan job with the photoId and its quarantine key.
S2The scanner reads the quarantined object. If the file is clean, the scanner moves it to originals/ and deletes the quarantine copy.
S3The scanner sends its verdict back to the API. Clean: status becomes scanned, and the scanner starts the resize flow (R1). Infected: the object is deleted, status becomes rejected, the app shows "Upload blocked", and nothing goes onto the queue.

Resize: one original becomes three thumbnails

This part is asynchronous. The queue absorbs bursts, and workers scale with queue depth.

R1Only for clean files, the scanner enqueues {photoId, sizes: [150, 600, 1200]}.
R2A worker pulls the job. The message stays hidden from other workers for 60 s while the worker processes it.
R3The worker reads the original from originals/{photoId}.
R4The worker writes thumbs/{photoId}/s.webp (150 px), m.webp (600 px), and l.webp (1200 px). The keys are deterministic, so a retry overwrites any earlier attempt instead of adding duplicates.
R5The worker sets status = ready and saves the three keys, then acks (deletes) the message. The next poll from the app returns the thumbnail URLs.

When a resize fails

Typical causes are a corrupt or truncated file, an unsupported format, a worker running out of memory, or a timeout. The upload itself is never lost because the original stays in originals/.

F1The worker hits an error and nacks the message. It becomes visible again after a backoff (30 s, then 2 min), and another worker picks it up through R2.
F2On the third failed attempt, the worker writes status = failed, using the same database path as R5. The app shows a placeholder tile with a "Try again" button instead of spinning forever.
F3After 3 receives, the queue moves the message to the dead-letter queue, so one bad file can't block the queue.
F4When the DLQ depth goes above 0, the on-call engineer is paged.
F5After a fix ships, on-call replays the DLQ into resize-jobs. R2 through R5 then run again, and any partial thumbnails are overwritten.

Delivery: thumbnails reach viewers

Only thumbs/ is exposed, and only through the CDN.

D1When the status is ready, the app requests img.sleetgarden.app/thumbs/{id}/m.webp (S for grids, M for feed, L for full screen).
D2On a cache miss, the CDN fetches the object from storage using signed origin access.
D3Storage returns the bytes. Because the keys never change, the CDN caches them for a year.
D4The CDN serves the image. Later viewers get it straight from the edge cache.

Principles

Nothing is resized or served until it has passed the virus scan.
Uploads return quickly (202). All the heavy work runs asynchronously behind a queue.
Thumbnail keys are deterministic, so retries are safe and the CDN can cache them indefinitely.
A failure is visible to the user (failed), recoverable (DLQ replay), and never loses the original.