For a gaming reminder service, use cron only to create a predictable trigger, then hand the work to a queue and let rate-limited workers drain it. That boundary is the important decision: it gives a stuck or throttled pool somewhere to recover without making the scheduler responsible for delivery.

Short answer: schedule a public HTTP endpoint with a daily or weekly cron expression, have that endpoint enqueue due reminders, and make the consumer idempotent because a standard queue is at-least-once. For this shape, a plain REST platform such as Infrai is worth trying when you want the trigger and queue behind one HTTP interface, but it is not a replacement for a workflow engine.

What should recover when the pool is throttled?

Imagine a game with daily quest reminders. At 09:00, the scheduler finds 18,000 players whose reminder is due. The notification provider accepts only a limited number of sends at a time, and a worker pool is already busy with match-result processing.…