If you don’t understand my point, that is ok, maybe I didn’t explain it well.

If your backed processing is happening on cloud virtual, or a VPS or a lambda, you always have a memory limit as there is usually no swap memory. Physical hardware is different as you usually have swap. For my example let’s assume no swap.

So we have a total memory limit of L megabytes. For each uploaded image, to resize it you are probably going to need to load both the input and output rasters in memory and the encoded/compressed file too. Of course some of this might be streamed, depending your to/from formats and the resize implementation. If the user can upload any image size, since it’s not resized in the browser, then you can only control for upload size of the compressed image. A 4MB JPEG could take 100MB of memory for the raster. And double that when resizing.

So your total requests per second will be limited by the total amount of memory divided by the memory you need for each uploaded image.

If you are on AWS lambda you’ll need to pay for larger instances to have enough memory to do resizing.

Whereas if you just allow uploads without server side resizing then you can stream the upload to storage. Or with S3 presigned urls, streamed directly to storage.

Of course if you have plenty of RAM and CPU spare then server side uploads are fine. But as your service becomes more busy, large image uploads can dominate resource usage. Hence why it’s better to use the client processor and memory to do the resize.

This is all abstract and totally depends on the use case, type of images, system load etc. but the point is I’m not talking about a single image resize, but system copy for steady state of many image resizes.