Not everything belongs in the request
Send the email later. Resize the image later. Return a 202 and an id, and stop holding a socket open while a third party thinks.
A handler that sends an email, generates a thumbnail and calls a payment provider has three ways to fail and one response to describe them all. Worse, the user waits for the slowest of the three, and a serverless platform will kill the whole thing at its timeout, leaving you with a charge taken and no email sent and no record of which.
The alternative is to do the smallest durable thing, write the record, enqueue the rest, and return 202 with an id the client can poll or subscribe to. This is more moving parts and it is genuinely more work, so apply it where the operation is slow, external or retryable, and not to everything.
The rule of thumb that holds up: if the user is waiting to see the result, it stays in the request. If they are waiting only because your code is doing it now, it can move. Uploading a video is a job; validating the form is not.
You should now be able to
- Identify work that should be moved off the request path
- Design an accepted-then-poll response
- Explain what a request timeout does to a half-finished operation
Loading…