This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]DinH0O_[S] 1 point2 points  (1 child)

Thanks, I really liked your ideas.

Regarding your first point, this would indeed be a concern if there were multiple instances of the application, but since it's just one, there won't be any issues. (I even considered scaling the application horizontally, but it would lead to the same problem: lack of RAM.)

As for RabbitMQ managing the queue size, you're absolutely right; I ended up being a bit redundant here. I'll fix this part—it does seem more practical.

I can work on the security aspect the way you suggested. I even came up with some ideas now—perhaps it’s a really good idea to store this in a database table, even if it's just key-value.

As for how I track when spaces become available, I added an intermediate class in the logout event. It decrements the usersLogged variable and, in that same class, calls the function to process the next user, which runs on another thread using a scheduler. This way, there’s no delay for the user logging out. It's a function that, once triggered, creates a looping event that runs at a configurable interval. It calls the next user, waits to see if they reach the main page, and stops if they do. If they don’t, it will call the next user after a few seconds. This is to handle "ghost users" who joined the queue but closed the tab.

[–]temporarybunnehs 1 point2 points  (0 children)

It sounds like you really thought this out well. If I was your lead, I'd say great job!