
Show HN: An API for scheduling queue messages - Flicflac
http://www.schedulerapi.com
======
evangelosdotnl
Hello Michael, congratulations for the launch! I've have a question; Why would
you need to have a delay of delivery at the first place? because of scaling
reasons or what exactly? I've seen that in enterprise usage of Apache Kafka, a
lot of people go with such implementations for queuing messages:
[https://martinfowler.com/bliki/CQRS.html](https://martinfowler.com/bliki/CQRS.html)
. Would love to hear your thoughts on this!

~~~
Flicflac
Hey evengelosdotnl, great comment. A lot to unpack here. To address both
points:

>>>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.

~~~
evangelosdotnl
Hello Michael, and thanks for your message! I understand what you mean and
you've got a point! nice!

Regarding CQRS, it is indeed a really interesting concept, and it also allows
you to easily scale up. The issue is that it's hard to convince people as they
used to the RDBMS day of thinking.

> That could explain why scheduling queue messages has never been a first
> class citizen in any MQ so far.

Exactly! The concept of CQRS is quite old, but back in the day, it was
difficult to challenge Oracle. We are getting back to the fundamentals
though..

If you are interested, check this guy;
[https://www.youtube.com/watch?v=v2RJQELoM6Y&feature=emb_titl...](https://www.youtube.com/watch?v=v2RJQELoM6Y&feature=emb_title)

~~~
Flicflac
Hey evangelosdotnl,

Tech talks usually make me fall asleep, but that was an amazing talk. Thanks
for sharing.

I'd love to chat more sometime. Please reach out to me at schedulerapi (at)
gmail.com if interested.

------
Flicflac
Hi! I'm Michael, co-founder of Scheduler API.

Scheduler API is for you if: 1) you use queues (eg SQS, Rabbit MQ, Kafka) 2)
need to delay delivery of your queue messages.

I came across this problem at work, when I had to build a scheduler service to
delay emails. Building and maintaining it was so difficult that I wish there
was an API that could handle scheduling for me. That API is Scheduler API!

If you have any use cases, or would like to chat, please email me at
schedulerapi@gmail.com. I'd love to meet you!

I'm also here to answer any questions you have :)

