Message Scheduler vs NAK-with-delay for scheduled notifications at scale (PS: Slack Invite broken?)

[jan-krueger]

Hi,

We're building a push notification service and evaluating the JetStream Message Scheduler (ADR-51) for delayed delivery.

Currently comparing two approaches:
Option A: Native Scheduler (ADR-51)

Publish to: schedules.<notification-id>
Headers: Nats-Schedule: @at <time>, Nats-Schedule-Target: notifications.live

Option B: NAK-with-delay

Publish to target subject with X-Scheduled-At header
Consumer checks header, calls NakWithDelay(remaining_time) until due

Questions:

1. Is the native scheduler designed for this scale (many unique schedule subjects, long-running schedules)?
2. Any concerns with 100K+ pending schedules per stream?
3. Would you recommend NAK-with-delay instead for this use case or an entirely different approach?

Thanks!

PS: It also seems like the Slack invite is broken. No matter what method (Email, Google, or Apple) I tried, I always got a "Couldn’t create account. Go ahead and try again — if the problem persists, you can always contact Slack.". I know that it says to contact Slack there but there is no obvious way to actually contact Slack. Is the invite link maybe expired?

[MauriceVanVeen]

Would definitely recommend using the new 2.12 scheduling feature over NakWithDelay, since Nak is not meant for that purpose and only really works as a workaround because the 2.12 scheduling feature wasn't there before. It should support a very large amount of schedules since it's built on top of the per-message TTL work which similarly also supports a very large amount. But, it's always good to test for your use case 😄

[MauriceVanVeen]

RE: Slack invite, could you perhaps keep trying a couple more times? It seems to be working on our end. If it doesn't work, could you reach out to Ginger via email: ginger@nats.io?