2 ms·
Yeah, my first thought was curiosity about their volume needs. DB based queues are fine if you don't need more than a few messages a second of transport. For t
by tracker1 4y ago
Yeah, my first thought was curiosity about their volume needs. DB based queues are fine if you don't need more than a few messages a second of transport. For that matter, I've found Azure's Storage Queues probably the simplest and most reliable easy button for queues that don't need a lot of complexity. Once you need more than that, it gets... complicated.
Also, sharing queues for multiple types of jobs just feels like frustration waiting to happen.
- TexanFeller 4y ago> DB based queues are fine if you don't need more than a few messages a second of transport I'd estimate more like dozens to hundreds per second should be pretty doable, depending on payload, even on a small DB. More if you can logically partition the events. Have implemented such a queue and haven't gotten close to bottlenecking on it.
- tracker1 4y agoHad meant few hundred... :-)
- eastern 4y agoA column in the database identifying which 'queue' is all you need for that. The table is not a queue, it's a structure to store queues.