Short answer: keep the searchable avatar record in a tenant-scoped database index, and keep the image bytes in private object storage; content type and tags can describe an object, but a prefix-only list should remain an inventory tool rather than becoming the customer request path.

That is the least complex design that gives an authenticated fintech customer a predictable answer. The database decides which avatar is active and whether the caller may see it. Object storage serves the exact key. A list by prefix is reserved for reconciliation, cleanup, and capacity work.

The incident lesson: discovery is not authorization

The production scenario I plan around is a report-serving account page for several tenants. A customer requests a generated report, and the page also needs the customer's current avatar. An early implementation can look for an object whose content type is image/png , whose tags include avatar , and whose key starts with the tenant prefix. That sounds like a storage query.…