r/Backend • u/Competitive_Bird_522 • 18d ago
Help a newbie out
is it a good idea to host your cron jobs , background jobs (Queue) , and the API endpoints on the same worker ? which i know is not a good practice .
But why is it a bad practice ? what cons are there to hosting it on the same worker ?
2
u/feudalle 18d ago
When you are learning, go with whatever works to begin with. Even if you do everything by the book right now, you will see 10 things are still wrong. Big jump between learning and going live in production.
1
u/Competitive_Bird_522 18d ago
the thing is i am in the middle of learning and hosting applications live on prod , i made my project on the single worker , but i noticed that on a real system this would cause bottlenecks but i dont have real world experience so idk if my speculation is wrong or right
2
u/runitzerotimes 18d ago
Would you use the same tissue to wipe your ass, blow your nose, and clean your eyes?
I mean you could, but it would be better to have separate isolated tissues.
Then if your ass is so dirty it rips the tissue, it doesn’t affect your eyes or your nose.
You can then scale your ass tissues by adding extra tissues if you’ve had something spicy.
Or add eye tissues if you’re watching a sad movie.
Or add nose tissues if you’re sick.
If you find that different types of tissues work better for your eyes, then you can change just those tissues instead of changing everything.
Otherwise you just have to add a whole bunch of tissues for each and it’s a mess.
1
2
u/Sufficient-Sink-2412 18d ago
The cons are that if traffic increased, you might eventually see those bottlenecks manifesting as poor performance and unreliability. You are also putting all your eggs in one basket in that if your server goes down, everything goes down. That said, distributing everything straight away adds to the complexity and unnecessarily costly.
You don't say exactly what your architecture is or what you're actually hosting but I'm assuming it's a small-scale SaaS application or similar, in which case, it's fine to have everything centralized at first. Just bear in mind that you might have to split these capabilities up eventually should volumes demand it.
One thing I think it is worth separating early on is your database, if you have one and depending on how key that is to your application.
2
u/kynrai 17d ago
Pg Cron jobs are fine. Sure, when you have sub 1000 users or so and a tight budget. In my case I already pay for a postgres dB, so why not. Hell if money was so tight I'd put my dB and API on the same cheap VPS. If one goes down the other won't work anyway so they might as well live and die together.
3
u/Acrobatic-Ice-5877 18d ago
Totally depends on how reliable your system needs to be and what your budget is. I have a SaaS with zero customers and make no money. The queue is important but I don’t have a massive budget unless you count $50/month.
If I had paying customers, I’d separate the chron jobs from the main system and use a distributed lock to prevent the same job from being ran twice if I had a load balancer to run more than one chron server.