It's essentially the arbitrariness of that 10,000 number that I'm queasy about.
e.g. When I thought of a "reasonable" maximum number of attachments on an email I'd probably say 64.
e.g. When I thought of a "reasonable" maximum number of attachments on an email I'd probably say 64.
We should not be talking of a "reasonable" maximum at all.
Rather, the maximum should be orders of magnitude away from the "reasonable".
At this distance, any arbitrariness quickly fades into meaninglessness.
Detached from the "reasonable" usage, the maximum then becomes informed by processing cost and complexity analysis, which are more concrete.
I think that may not always be true though. Especially for highly variable workloads.
How many requests per seconds does your site handle on average vs how many can it handle? What about spikes?
If your previous peak is at 10 rps and you can probably handle 20 rps, when should you start dropping connections to keep the site up?
Most systems are designed to have small margins, for cost purposes, so I imagine this sort of situation might come up quite a bit.
The correct response to a breach of this limit would be for a reply email to explain the limit and why the email was rejected.
The user then could send multiple emails with their attachments, and the system can be sized to handle e.g. 24 threads processing 64 attachments of a maximum size of e.g. 4096kb
That's how you ensure a system sized to your hardware and ensure maximum throughput for all users.
Sure, I think we are actually in agreement. That's exactly what I meant by "processing cost and complexity analysis".