A team is deciding whether to let clients upload directly to object storage via pre-signed URLs, or keep proxying uploads through their application server. Name two concrete scenarios where proxying through the app server is the better choice, and explain why the Valet Key pattern falls short there.

## What the pattern optimizes for The Valet Key pattern optimizes for one thing very well: **removing the application server from the data path** of a storage transfer. That optimization comes at the direct cost of removing your application's ability to inspect, transform, or make request-time business decisions about the bytes as they move, because by design those bytes never pass through code you control. Two classes of requirement expose that cost clearly. ## Inline content validation or transformation The first is inline content validation or transformation. Consider a requirement that: - uploaded files must be virus-scanned before they're considered accepted, - or that an uploaded image must be resized or watermarked before it's usable, - or that a document must be validated against a schema before downstream systems trust it. With Valet Key, the client writes directly to storage; your application server never sees the bytes in flight, so it cannot reject a malicious upload before it lands, nor transform it inline. The only recourse is **post-hoc**: react to the object's arrival via a storage event notification, such as an S3 event triggering a Lambda or an Azure Blob trigger firing a Function, scan or transform it after the fact, and then either delete or quarantine it or move it somewhere the rest of the system trusts. That introduces a **race window**, since anything that reads directly from the upload location between the write and the scan completing sees unvalidated content, and adds asynchronous complexity such as: - retry logic, - dead-letter handling for failed scans, - and eventual-consistency handling for consumers. If the business requirement is that nothing unscanned is ever visible, proxying the upload through the app server, running validation synchronously, and only then writing to storage is simpler and closes that race entirely, at the cost of the app tier paying for the bandwidth and compute of every byte transferred. ## Request-time business authorization The second is request-time business authorization that depends on state the storage service has no way to evaluate. A pre-signed URL's permissions are **frozen at the moment it's issued**; the storage service only checks whether the signature matches and whether the request falls inside the time window, it doesn't call back into your application to ask whether this user is still under their storage quota right now, or whether their subscription was cancelled in the last thirty seconds. If your business rule needs to be evaluated at the moment of the actual transfer rather than at token-issuance time, Valet Key introduces a **time-of-check-to-time-of-use gap**: the token was valid when issued, but the business state it was predicated on may have changed by the time the client actually uses it, and nothing stops them from using it, possibly repeatedly if the scope allows multiple uses, up until expiry. Proxying every request through the app server lets you re-evaluate that business state on every single transfer, which is exactly the guarantee some domains require, such as: - metered billing per request, - hard real-time quota enforcement, - or per-transfer audit logging with business context attached. ## The middle ground None of this means Valet Key is wrong for these systems wholesale; it usually means picking a middle ground rather than an all-or-nothing choice. 1. A common compromise for the validation case is the **quarantine-bucket pattern**: uploads land in a bucket nothing downstream trusts by default, an event-driven scanner promotes clean files by copying or moving them into the trusted bucket, and consumers are pointed only at the trusted bucket, accepting a short propagation delay instead of full synchronous inspection. 2. For the business-authorization case, teams often keep tokens **single-use and short-TTL**, seconds to low minutes, so the time-of-check gap is small enough to be an acceptable risk, or they issue one token per logical operation rather than one reusable token per session, shrinking the gap between checked and used to something close to negligible. ## The broader principle The broader principle for choosing between the two designs is that Valet Key trades away inline, synchronous control over the data plane in exchange for taking the app tier's compute and bandwidth off the critical path of every transfer. When the business genuinely needs that inline control, because unscanned or unvalidated content is unacceptable even briefly, or because authorization must reflect state that can change between issuance and use, proxying through the app server, even at higher infrastructure cost, is the safer default. Valet Key earns its keep specifically when the transferred bytes are large, frequent, and don't need synchronous business logic applied to them.