How to handle requests that have heavy load?

Question

This is a Brain-Question for advice on which scenario is a smarter approach to tackle situations of heavy lifting on the server end but with a responsive UI for the User.

The setup; My System consists of two services (written in node); One Frontend Service that listens on Requests from the user and a Background Worker, that does heavy lifting and wont be finished within 1-2 seconds (eg. video conversion, image resizing, gzipping, spidering etc.). The User is connected to the Frontend Service via WebSockets (and normal POST Requests).

Scenario 1; When a User eg. uploads a video, the Frontend Service only does some simple checks, creates a job in the name of the User for the Background Worker to process and directly responds with status 200. Later on the Worker see's its got work, does the work and finishes the job. It then finds the socket the user is connected to (if any) and sends a "hey, job finished" with the data related to the video conversion job (url, length, bitrate, etc.).

• Pros I see: Quick User feedback of sucessfull upload (eg. ProgressBar can be hidden)
• Cons I see: User will get a fake "success" respond with no data to handle/display and needs to wait till the job finishes anyway.

Scenario 2; Like Scenario 1 but that the Frontend Service doesn't respond with a status 200 but rather subscribes to the created job "onComplete" event and lets the Request dangle till the callback is fired and the data can be sent down the pipe to the user.

• Pros I see: "onSuccess", all data is at the User
• Cons I see: Depending on the job's weight and active job count, the Users request could Timeout

While writing this question things are getting clearer to me by the minute (Scenario 1, but with smart success and update events sent). Regardless, I'd like to hear about other Scenarios you use or further Pros/Cons towards my Scenarios!?

Thanks for helping me out!

Some unnecessary info; For websockets I'm using socket.io, for job creating kue and for pub/sub redis

Answer 1

Scenario 1 -- but instead of responding with 200 OK, you should respond with 202 Accepted. From Wikipedia: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

This leaves the door open for the possibility of worker errors. You are just saying you accepted the request and is trying to do something with it.

Answer 2

I just wrote something like this and I use both approaches for different things. Scenario 1 makes most sense IMO because it matches the reality best, which can then be conveyed most accurately to the user. By first responding with a 200 "Yes I got the request and created the 'job' like you requested" then you can accurately update the UI to reflect that the request is being dealt with. You can then use the push channel to notify the user of updates such as progress percentage, error, and success as needed but without the UI 'hanging' (obviously you wouldn't hang the UI in scenario 2 but its an awkward situation that things are happening and the UI just has to 'guess' that the job is being processed).