Short answer: move thumbnail processing into a bounded worker, measure decode/resize/encode/upload separately, and upload only a finished, tenant-scoped object; Infrai fits this boundary when a plain REST adapter is more important than native versioning, conditional writes, or replication.

When a customer-support export times out while uploading a thumbnail, the storage call is often the innocent part. The expensive work happened earlier: decoding a large source image, rotating it from EXIF metadata, resizing it, encoding it, or buffering the whole result in memory. The fix is to measure those stages separately, bound the work, and make the export job produce tenant-scoped object keys before it asks storage to accept the bytes.

The practical rule is simple: keep resizing off the request path, record a duration for every stage, and give each thumbnail a deterministic key such as tenant-42/ticket-981/thumbnail-320.webp . A storage provider should receive a finished, bounded object.…