Short answer: Put the deadline on a scheduler, publish small cleanup jobs to one queue, and let multiple Python workers consume them. Acknowledge only after an idempotent state change is durable.

That split is the practical answer for a game that must delay a renewal reminder until a business deadline. Operational recovery is the deciding constraint: a worker can disappear after receiving a job, and a standard queue can deliver that job again. The cleanup therefore needs a durable idempotency key and a state check that protects a newly renewed account.

This is an architecture decision record. The invariants are narrow: the scheduler starts work, the queue distributes work, and workers own the long-running cleanup.…