Short answer: keep the original image in object storage under an application-owned, user-scoped key, and treat the database as the authority for retention and deletion. For a media service processing receipts, large-file throughput should decide the upload path first; lifecycle cleanup and user-requested deletion are separate controls with separate SLOs.

The useful design is boring: one immutable object key per source file, a small record describing that object, bounded workers, and an audit trail for every deletion decision. A folder is only a prefix in a flat object namespace. It is not an access-control boundary, a transaction, or a substitute for metadata.

How should I store generated images per user folder?

Use a key that is difficult to confuse with another receipt, for example users/{userID}/receipts/{receiptID}/original.png . Generate receiptID server-side, store the complete key in the database, and keep the original separate from derived previews.…