I'm designing a solution in which users perform tasks based on task queue. The point is to create system, where user goes on specific URL and server serves him listing with for example: items to asses and put into specific predefined category - like StackExchange's queues (First Posts, Late Answers and Triage).

What I'm struggling with is making sure that users will get different tasks to do and no user will get the same task other user is currently working on.

Obvious solution would be storing datetime when given task is served to user and have other service to monitor those tasks and release them to be available again if timeout occurred.

This solution however feels kind of "dirty". Like it's the most straightforward but might not cover all edge-cases.

I also struggle to formulate proper query for Google, because all results I get are about event buses and asynchronous tasks.

Is there any more clever way to solve this kind of problem?

  • 1
    Timeout is not that dirty: flight and concert booking work that way. – mouviciel Jan 29 at 14:00
  • 1
    Timeout could be driven by the type of task and you could also have your consumer send out beacon signal back to indicate its still being worked on so that it doesnt get reassigned. But even in this case you need to have a hard timeout so a user doesnt keep stalling the task. – Srinivas Jan 29 at 20:16

One edge case which is not covered by the Stack Exchange system is the situation where one user is still working on the review task but takes a long time to do it; another user will be offered the same review task and both users will be able to perform the same task. This can be mitigated by choosing a longer timeout (than the 5 minutes used by Stack Exchange); depending on the urgency of the tasks, 1 hour could work as well. Another solution would be to detect if the user is doing anything; any interaction with the page (key press, mouse scroll or click) can offset the timeout by another 5 minutes. Finally, you could use a WebSockets or a similar technology to push updates from the server; if the server assumes the user is idle, and another user starts on the same task, the server can send a message down the websocket instructing the client to close the task.

The latter is also something to keep in mind when tasks can be invalidated by external reasons. To keep the Stack Exchange analogy, if you review Close Votes and while reviewing a question it gets closed by other users outside the queue, you can't complete the review task. A websocket message from the server would be able to notify the reviewer that they can stop with their task since it has been invalidated.

hurries off to Meta Stack Exchange to post a feature request ...

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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