>>>Why would you need to have a delay of delivery at the first place?
1) Emails - Let's say you want to send a reminder email a month in advance. You usually put emails on a queue to go out, but since this is scheduled so far in advance, you need a way to store the request and publish it back to the queue to send a month later. Then you could use schedulerAPI + your emailService to achieve this reminder email effect.
You could extend this to any service that needs a delay. Eg if you need to schedule billing, you can call schedulerAPI + stripe API, delay texts you use scheduler API + twilio API, where each queue message is a request to bill or message someone).
2) Handling retries - Sometimes if a message fails you want to retry with exponential backoffs. This requires re-enqueuing the message with longer delays. You could just call schedulerAPI w/ longer delays to achieve this.
>>> CQRS Implementation for handling queues
Thanks for sharing this, I have never heard about this before. CQRS seems consistent with both scheduler API and microservices architecture in general. From my quick read of this, it's basically saying to spread out a monolith service that handles all CRUD operations in one service into separate services if the model for each operation is different. So instead of one service that handles all writes and reads to a table, you have two: one that handles reads, one that handles writes because the models for both are different.
Queue message scheduling fits well with CQRS. The queues and scheduling are different problems. The queues handle high throughput messaging, whereas scheduling is more of a storage problem (if you delay a request you need to store it somehow and pop-it out when you need it). So it makes sense based on CQRS architecture to separate the two out because they are fundamentally different models. That could explain why scheduling queue messages has never been a first class citizen in any MQ so far.