some of you should know what a login queue is. You start your game, like world of warcraft, league of legends, ..., type in your username and password, klick "log in" and then it happens: Login Queue, position: x.

What i want to ask is, what actually is a login queue on the serverside? I mean, if you take league of legends and klick log in, the server will first check your logindata and then place you in the loginqueue (or not, if your password is wrong). So what i don't understand is, why is there a queue. If the server had enough time to check your logindata, whats the problem by just setting the "is-loggedin" flag? Why is there a queue needed?

3 Answers 3


(If it is WoW specific question then the forums or the gaming stack exchange is a better place - My answer is more generic and is from patterns used in enterprise systems as well)

Login Queues are usually used in server side software systems that have limited total resources and Quality of Service parameters mandate that the user is allocated atleast a certain amount of resources on the server to have an acceptable user experience.

Example: In case of an online game, each user needs a certain amount of CPU cycles and memory space to have an acceptable user experience (like no lag). So game servers implement a queue so that too many users don't choke up the server resulting in a bad use experience for all the users. So if the authentication system simply sets a "is-loggedin" flag after validating your credentials then the total number of concurrent users will not be capped resulting in degraded performance for the users.

In enterprise systems, such mechanisms are used for heavy on-demand resources like remote desktops, etc.

  • This is not a WoW-specifiq question, this is why i placed it here. But to come back to your example: I do understand what you mean, and of course, thought about this. But the point is, that you WILL get logged in after a few seconds (maybe longer, depends), no matter what. So for example in league of legends, after a server-downtime, there is a really high chance that you end up in the loginqueue. But you will eventually get logged in after a few mins, and i do not really think that the users who logged in right after the downtime will log-out directly after this.
    – tkausl
    Dec 8, 2014 at 10:02
  • So what i'm trying to say is, that the loginqueue not necessarily have anything to do with the already logged-in players, but by the players who log in concurrent. So i was thinking about what the server has to do in the login-process what could take some time.
    – tkausl
    Dec 8, 2014 at 10:05
  • The servers usually run in clusters and they provision new nodes when there is a long queue, since keeping users in queues is also not very good from usability perspective. In case of cloud based servers the provisioning is much simpler via APIs, in case of a self hosted data center the provisioning might involve physically booting up machines which are kept on standby. Similarly, when the overall load is less, active servers are de-provisioned.
    – Jit B
    Dec 8, 2014 at 10:06
  • @tkausl Remember, even if all you want to see is a list of 'games I can join', the system may be doing a lot of things that you don't see (such as logging information about your log in and verifying it to past behavior to see if it is an anomaly) and it may also be doing this in a less than efficient manner, especially for systems that have years if not decades of legacy code running in spots. Dec 8, 2014 at 15:55
  • I'd note that it is also used when a game has many servers. Then this queue serves as a way to always put the next requested login on the server which has the most resources available. Sort of like a load balancing. Dec 8, 2014 at 16:38

On the simplest level, the server received a username and password and asks the database 'do you have a username and password hash that matches this'. The database then says either yay or nay. That is quick and doesn't require much of a queue. For user experience reasons, this is done with priority, as you don't want a user to wait 5 minutes to find out they mistyped their password.

But, there is often more work that needs to be done before one is actually 'in' the system. For example, are you a first time user. Is your subscription paid. Do you have any new notifications awaiting you. What security access should you be given. What about running any logic that is supposed to run on user log in. All that requires resources before you can be given the welcome screen. As I've mentioned, the 'is the password correct' is done with far higher priority for reasons of user experience, but the rest of this requires sitting in the queue.

For most applications, this is so small a demand that you don't see a queue until you go use a far more demanding part of the application. For many business systems, logging in doesn't require a queue, but running a report does. But it is possible for a system to be under such demand that it doesn't have the resources to immediately display a welcome screen and thus has to put you in a queue until enough resources are ready to handle your request.

One should note that complex systems can require login queue to different parts, even if you don't actually have to re-authenticate. For example, you login to a system, you get put in a queue until enough resources are available to judge your access level, determine notifications, and run background business logic. Then you click on a report button, and get stuck in a short queue until enough resources are available to authenticate you in the report system (using information passed in from the previous system) and return the list of reports you are able to run. Then you click a report, enter the data, and are put into a much longer report queue while you wait for enough resources to run your report.

For online games in particular, there is both a queue to get into the main interface and a queue to get into the game, as the user interface/account management is often separated from the actual game for various reasons (for example, having all your account servers in one location, even if it gives some users greater latency, isn't a problem as 75ms vs. 300ms latency while handling account interactions isn't a big deal, but you want your game servers closer to give the least latency possible because 75ms vs. 300ms is a big deal during game play).


Additional to Jit Bs answer, I think especially for LoL it is not just the fact that you can login, but rather that you can then start a game. Starting a game seems to aquire quite some serverside resources, having a game running, too. Therefore, if all the people login at once and start a game and play there will be a huge peak in the need of server resources. However, if you have to wait 20 minutes to login, a few players will already be finished with their game.

  • From a user experience standpoint, it would seem the better way to handle this is to put a queue on 'start a game' while letting a user still do other non-demanding activities (even if 99% of users just want to start a game). Dec 8, 2014 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.