"But that server is faulty!! If it has to handle multiple requests at once, it starts to break down."
Ok. I know this is all hypothetical. But I don't buy this premise.
Why is the server faulty ? In what way does it fail ?
How do you know it's because it's processing more than one request at a time ?
What if there are multiple clients each doing one request only ?
Do you have control over the server code ? If so, fix it there!
---
The point is, this solution is fixing the wrong problem and introducing a new one down the line.
If the bug on the server gets fixed, you've now implemented an artificial performance bottleneck on the client.
Devs who know about it are going to leave the org, others are going to try to 'optimize' the code around it with other hacks, since by allowing these kinds of fixes you're building to the wrong kind of culture.
Always fix the root issue.
Ok. I know this is all hypothetical. But I don't buy this premise.
Why is the server faulty ? In what way does it fail ? How do you know it's because it's processing more than one request at a time ? What if there are multiple clients each doing one request only ? Do you have control over the server code ? If so, fix it there!
---
The point is, this solution is fixing the wrong problem and introducing a new one down the line.
If the bug on the server gets fixed, you've now implemented an artificial performance bottleneck on the client.
Devs who know about it are going to leave the org, others are going to try to 'optimize' the code around it with other hacks, since by allowing these kinds of fixes you're building to the wrong kind of culture. Always fix the root issue.
Or change the premise of the problem.