[FR]: Job ordering

[ewhauser]

In some systems, you need to guarantee order across a given partition key while still having multiple queue consumer threads. SQS has the concept of FIFO queues that we currently use for this.

The canonical use case a high volume SMS system where you are sending multiple messages to a specific customer and always want to send them in order.

[brandur]

This does seem like something that might be useful in the project — I've seen the same kind of thing elsewhere too.

I'm not sure we're likely to get to this right away, so I'd suggest this workaround in the meantime: using the SMS example again, instead of putting the SMS messages directly in a River job, hold them instead as a separate database model that's ordered naturally on insert order. Then, your River job runs and just clears whatever SMS messages it finds in the database:

func (w *SendSMSWorker) Work(ctx context.Context, job *river.Job[SendSMSArgs]) error {
    ...

    messagesToSend, err := queries.SMSMessageLoadByUser(job.UserID)
    ...

    for _, message := range messagesToSend {
        // send SMS message
    }

    return nil
}

[fsaintjacques]

The issue is with concurrent workers draining from the same partition. You can hack this with postgres' advisory locks but now you've entered deadlock territory or simply highly unbalanced partitions (hello multi-tenant) can bring the system to a halt.

The goal here is that workers handle this transparently for you.

[bgentry]

FYI, this functionality is now part of sequences in River Pro ✨

[sharlenaluyen]

Is there code or examples regarding sequences in the River repo that you can link me to, per chance?

[bgentry]

The best source is the docs: https://riverqueue.com/docs/pro/sequences

The riverpro Go package docs don't currently have an executable example for sequences.