Size limited Queuing

Basically just want to know if you have any insights to share - I’ve been plowing through my TCG (trading-card game) and I’ve reached the point of designing a drafting system. The way it works is as with any draft - there’s a limit of players who can join, and then X random elements/cards are chosen into a pool from which players take turns picking their choices (in fact it’s several pools but that’s just an implementation detail).

So my idea is to have users join a draft queue on the lobby. This queue will need an exact number of players to start. Once it’s filled, reset, rinse and repeat. So say 10 players, you would have player 1 join, player 2, join, etc once player 10 joins it fires a draft “pod”, resets itself and new players joining will be part of “another” queue.

What would be a scalable and OTP way of handling this?

My first naive approach (pseudo, not implemented) is to have a genserver that holds a list of players as its state. [player_a, player_b, …] . Once this list reaches the exact needed number it calls a supervisor, that starts another independent genserver for this “pod” of players. It resets itself, and starts again from zero players, repeating over and over until the sun dies.

Never having designed systems at scale I wonder if this is an ok approach imagining I wanted it to be scalable? My main concern is that the genserver could be overrun with requests on its mailbox - which is a reasonable concern right? At the same time, the genserver itself would be only doing synchronous push/pop operations on a very very tiny list, and firing off the “pod”, ack the requests to join the list, and ack the requests to be removed, so I don’t imagine it to be a problem unless it’s being hit by thousands of concurrent requests? Everything else would be handled on the websocket and on the other genservers.

The problem is also not one of “pooling” (in my understanding?), since I don’t want to spread players across resources, I want all players to join the same queue, in the order they “ask” for joining, until it’s filled up, and then start a new queue.

Appreciate your thoughts! Thanks

All of your logic sounds pretty spot on to me.

I will post back when the game is up!

btw: saw a talk by you and another guy (can’t remember who …) also on the topic of game implementations and really liked the idea of storing the game evolution as transformations that can simply be replayed. I’ll probably end up doing a similar approach for replaying games :metal:

1 Like