1

I'm trying to figure out a design pattern for scheduling events in a stateless Node back-end with multiple instances running simultaneously.

Use case example:

  1. Create an message object with a publish date/time and save it to a database
  2. Optionally update the publishing time or delete the object
  3. When the publish time is reached, the message content is sent to a 3rd party API endpoint

Right now my best idea is to use bee-queue or bull to queue delayed jobs. It should be able to store the state and ensure that the job is executed only once. However, I feel like it might introduce a single point of failure, especially when maintaining state on Redis for months and then hoping that the future version of the queue library is still working.

Another option is a service worker that polls the database for upcoming events every n minutes, but this seems like a potential scaling issue down the line for multi-tenant SaaS.

Are there more robust design patterns for solving this?

Viktor
  • 56
  • 4

1 Answers1

0

Don't worry about redis breaking. It's pretty stable, and eventually you can decide to freeze the version.

If there are jobs that will be executed in the future I would suggest a database, like Mongo or Redis, with a disk-store. So you will survive a reboot, you don't have to reinvent the wheel, and already have a nice set of tools for scalability.

Mascarpone
  • 2,516
  • 4
  • 25
  • 46