-
Hi, Suppose I have a turn based game where each battle can have two players. As players take turns they hit the webserver endpoints, I want to ensure that turns happen in a single threaded manner to prevent invalid states, I want to do this with BullMQ rather than DB transactions or any of that junk. So suppose PlayerA and PlayerB both attempt to take an action at the exact same time. Webserver1 and Webserver2 both push push their "take turn job" onto the Queue. Now all I have to do is have a Worker with a concurrency set to 1 to ensure that this is single threaded. The problem is ALL battles are now going to share the same queue and worker which is a potential bottleneck. I would ideally like it so that different battles can be processed in parallel but a single batlle must be processed in a single threaded manner. Is this possible? I was looking at the Group Keys (https://docs.bullmq.io/guide/rate-limiting) but I think thats only rate limiting and not what im trying to solve. Thoughts? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
BullMQ makes the best effort to keep the order of the jobs, and this applies also to the group functionality in the pro version. However, there are some edge cases where this is not possible, this is mostly due to some limitations in Lua script (lacking support for blocking calls), but in practice, if you have distributed jobs running on several workers it is practically impossible, it kinds of defies the laws of physics. So without having all the requirements of your use case, I would say that you probably need something like Postgres and take advantage of its ACID guarantees in order to implement your "turn per player" requirements. Maybe BullMQ can be used for offloading heavy jobs in your game, but I think you need something like a SQL database as a single source of truth. |
Beta Was this translation helpful? Give feedback.
-
I asynchronously receive Kubernetes events across an entire cluster. I create jobs based on these events that I receive and can not guarantee the order they are received or submitted as jobs. The way I worked this was to create a global locking with Mongo (ensuring it's a single transaction). I then use a limiter with a value of |
Beta Was this translation helpful? Give feedback.
BullMQ makes the best effort to keep the order of the jobs, and this applies also to the group functionality in the pro version. However, there are some edge cases where this is not possible, this is mostly due to some limitations in Lua script (lacking support for blocking calls), but in practice, if you have distributed jobs running on several workers it is practically impossible, it kinds of defies the laws of physics.
So without having all the requirements of your use case, I would say that you probably need something like Postgres and take advantage of its ACID guarantees in order to implement your "turn per player" requirements. Maybe BullMQ can be used for offloading heavy jobs in …