When to use queues and jobs?

@Tippin But imagine if I have 1000 users creating a project at exactly the same time.

It is better to use a queue, to avoid overload the database?

@miguellima no

save queued jobs for tasks that are resource intensive. You will spend longer creating and serving the queued job than just creating the project

creating a queued job to do the work is adding a wrapper around the work to create a project

if you have 1000 users creating a project in the same second then you must have millions of users so give yourself a pat on the back and scale up your solution

Think of it this way, is it quicker for you to do a job, or to write out a full description of the requirements and give it to someone else? You will say it depends. if you have more valuable things to do, and the work takes a long time to execute then it's probably better to give it to someone else despite the initial overhead

But imagine if I have 1000 users creating a project at exactly the same time.

@miguellima Are you really going to have 1,000 users creating a project at exactly the same time, though? I bet not even Jira has 1,000 users creating projects at exactly the same time.

@miguellima As @snapey said, no, if all you are doing is inserting/updating your basic models, then your database alone is more than capable of handling such task. But imagine your users create a project, and each time a project is created, you want to email that users followers that they created a new project. The controller should create the project, but imagine making the user wait around for the project POST to complete a cycle of emailing some unknown amount of users, that calls to a 3rd party API like mailgun, and could take anywhere from 1 second, to 10 seconds, or, that could fail, causing the entire request of making a project to fail. Instead, you would create the project and let the user get on with their day, returning a success right then. You would then queue a job to query all followers for that user and send an email to each one with the "Hey, User John added a new project! Check it out now!". That job is now processed behind the scenes, and if the mail API failed, you can easily retry the job at a later date, and all of this happens without impeding the initial user who created the project.

Same goes for scheduled task. Perhaps you want to automate a command to check your database every 15 minutes for new projects. When it finds new projects, it can dispatch a job with the project model, and the job can do whatever housekeeping you want, all automated, behind the scenes, asynchronously.

@martinbean No, but I will have an API.

Even if I have 10 users. I can't how much traffic they will handle. It can be 10 requests, 100 requests, 1000 requests.

What I was asking is what is the best way to do it! I just want to learn, nothing more. Just want code the better I can, and I came here hopefully get an advice from people o know better than me.

I'm not thinking I have a million dollar product, or it will have a million users.

I just want to know how you guys would approach it, so I wont overload my database or my server, if applicable.

@Tippin Thank you so much, that answers my question.

I was not sure if I should queue inserts/updates, because I was afraid to overload the database, when multiple requests could came at the same time.

Thank you!

Even if I have 10 users. I can't how much traffic they will handle. It can be 10 requests, 100 requests, 1000 requests.

@miguellima I think you’re overestimating request loads.

It’s going to be highly unlikely you’re going to have 1,000 requests at the exact same second. That’s just massive scale. You’ll know when you’re at that scale because if you have a product with that many concurrent users, then you’ll be working at a company that can afford to hire dedicated SREs.

Back to the original question, queues are used to process logic that doesn’t need to done before returning a response to a user. The common example is sending emails. A user doesn’t need to wait for an email to be sent before you return a HTML response back to them. You can put that on a queue, return the response, and the queue will send the email as soon as it can (almost instantaneously if you don’t have a backlog of jobs).

Another example would be generating thumbnails from an uploaded image. Once the image has been uploaded, you don‘t need the thumbnails right away to be able to return a response to the user saying, “Thanks, your image was uploaded.” You can dispatch a job to your queue to generate the thumbnails from the newly-uploaded image. The queue worker can do the heavy work of loading the source image into memory, generating thumbnails, and saving those thumbnails to disk. This is an intensive task and the user could be waiting a long time whilst your server did this depending on the size of the image uploaded and the number of thumbnails you needed to generate. You don’t want users staring at a blank, white screen and waiting around for a response whilst your server’s busy doing tasks that can be forked off to another process (a queue) and executed asynchronously.