[bhp]

The 101st request should not be allowed to negatively impact the experience of the other 100 users.

What about the 300th request? I guess it's a matter of opinion, but is it better to provide a mediocre (or worse) quality experience to all 300 users, or to provide a good quality experience to 1/3 of the users and deny the other 2/3 requests?

[skolor]

It would largely depend on how gracefully you degrade your service to those other 200 users. Take any game server with the concept of queues. They could (depending on the game, I know this isn't universal) take in more players than they allow at a time, but the quality would drop significantly. Instead, they give you a number, and say "You are number X in line. Please wait". While it isn't great, and is very frustrating for players, it is a decent solution.

On the other hand, you have Monopoly Street View, which launched with a massively higher number of players than they expected. The end result was a game that was playable for a very, very small group of people, and no one else even knew what was going on.

In general, you need to be able to balance the two. There should be a point where you have an absolute cutoff, no more users/requests beyond that, but you should also have a sliding scale. Of course a server only processing one request at a time will be faster, but you need to be able to degrade somewhat, while still providing good service.

[blackcat786]

The challenge is that by the time you reach the 300th request your system is unusable. In the example mentioned the system starts to experience exponential degradation around the 100th request. One wants to avoid reaching that state of the system where the exponential degradation starts . There IS a better solution to this than just rejecting the request and it has to do with request queuing.