0

This might seem as a very basic and maybe a vague question but I'd really appreciate advice and experience sharing on this:

Given you have a service, which processes tasks in a queue, e.g. because they might be time-consuming, or there might be too much of them coming in, or maybe because they require fifo order, if a client (e.g. web browser or another service, but let's assume web browser for simplicity) initiates such task, what are the best practices to give feedback and update it on the progress in simple cases?

E.g. consider a case when you resize pictures - you upload one, press "compress" and after that you can see a meter, reporting the progress, and eventually a link to download the resized version rendered. Consider that after submitting the picture the service doesn't hold the request, but just enqueues the job and responds with e.g. job id immediately. Given we don't use websockets or another streaming solution, what are the best practices to achieve seamless progress reporting (e.g. 5% completed, 50%, etc) and getting the result as soon as the job is done?

First thing which comes to my mind is polling, but that looks a bit workaround-ish (at least to me and at least right now) and can increase the load drastically, just because of those check requests.

Are there any better solutions? What are the best practices and patterns for that?

If this could be achieved only with a streaming or pubsub solution, pls suggest, I really wanna improve my understanding and get some ideas from experienced people.

Sorry if it's kinda vague, but it seems to me that it still raises some good design questions...

  • Does this help? softwareengineering.stackexchange.com/a/386998/6509 – Berin Loritsch Feb 20 '19 at 20:46
  • Are you looking for predictions (estimations) for processing time without any communications (no knowledge of actual progress)? – rwong Feb 20 '19 at 22:04
  • not predictions. presumably those values are available exactly (not predictably) but the communication is async – Tristan Tzara Feb 20 '19 at 22:11
  • @BerinLoritsch the approach with token is pretty clear, that's what I've mentioned in the question when said that request returns job id. This is more about if there're ways to solve the problem with something more elegant than polling by that id – Tristan Tzara Feb 20 '19 at 22:12
  • Specialized answers are applicable if each individual users have: (1) tens of jobs queued or in-flight; (2) hundreds of jobs queued or in-flight; (3) thousands of jobs queued or in-flight. If the typical user will have ten or fewer jobs at a time, the typical advice would be suitable. Several reminders: allow querying for multiple job IDs in one request (basically to batch the network transmission), make sure progress responses are not stale due to network caching, keep the response short and simple (unless a job requires user intervention), etc. – rwong Feb 20 '19 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.