Yes but have you built a tool for the job or a Rube Goldberg machine?
Complexity comes at a huge cost. Only add it when the benefits out weigh the costs.
You could start out building a product that could scale to millions of uses overnight. But if you do that you've spent months building something with no users. You could have been in the market already, building revenue already. Your requirements will change as you find your market fit and you'll need to change things. The less you have built the easier it is to change. Why not leave the million user capabilities until you actually need it?
> Yes but have you built a tool for the job or a Rube Goldberg machine?
> Complexity comes at a huge cost. Only add it when the benefits out weigh the costs.
Im honestly unsure if you mean this as opposing "doing everything in Postgres" or as opposing "throw more services on the stack".
Because both are true for the statements. You have that complexity, regardless of where you implement it. Either you are building the rube-goldberg machine inside of postgres out of modules, config and SQL or outside of postgres with additional services.
The only way to really solve this is to avoid building that RG machine in the first place. In this case: don't have queues. In practice that probably means introducting complexity elsewhere, though.
Most web apps I've worked on have had queues in the database. The operational simplicity of only having a database has far outweighed the code complexity of using the relational database as a queue. However the performance would not have scaled. Luckily the performance was well above peak load of the actual systems.
Complexity comes at a huge cost. Only add it when the benefits out weigh the costs.
You could start out building a product that could scale to millions of uses overnight. But if you do that you've spent months building something with no users. You could have been in the market already, building revenue already. Your requirements will change as you find your market fit and you'll need to change things. The less you have built the easier it is to change. Why not leave the million user capabilities until you actually need it?