RabbitMQ may have been overkill for the need, but it's also clear that there was an implementation bug which was missed.
Db queues are simple to implement and so given the volume it's one way to approach working around an mq client issue.
Personally, and I mean personally, I have found messaging platforms to be full of complexity, fluff, and non-standard "standards", it's just alot of baggage and in the case of messaging alot of bugs.
I have seen Kafka deployed and ripped out a year later, and countless bugs in client implementations due to developer misunderstanding, poor documentation, and unnecessary complexity.
For this reason, I refer to event driven systems as "expert systems" to be avoided. But in your life "there will be queues"
Db queues are simple to implement and so given the volume it's one way to approach working around an mq client issue.
Personally, and I mean personally, I have found messaging platforms to be full of complexity, fluff, and non-standard "standards", it's just alot of baggage and in the case of messaging alot of bugs.
I have seen Kafka deployed and ripped out a year later, and countless bugs in client implementations due to developer misunderstanding, poor documentation, and unnecessary complexity.
For this reason, I refer to event driven systems as "expert systems" to be avoided. But in your life "there will be queues"