Postgres holds the weekly digest schedule so an operator can see what is due

The design the post rejects is the tempting one: a cron expression for every customer, sending immediately inside the callback ^[10]. Per-user schedules are then hard to enumerate, the callback owns the work only while it runs, and a process restart leaves never attempted and sent but not recorded looking identical ^[10]. One global wake-up schedule plus a materialized next run for each customer makes those states explicit ^[11]. Cron's remaining responsibility is to wake a worker often enough to find due rows ^[7].

The schedule table uses five states ^[23]. `running` means one worker owns a lease, and `sent` means the provider accepted the delivery operation and the application committed that outcome ^[14]. Those are two events, and the post is explicit that sending an email and committing a database transaction cannot be one atomic operation ^[19].

Claiming is where concurrency gets decided. Multiple workers may wake at once, so each due row is leased to one while the others skip it ^[16]. Size the batch by time: keep it small enough that the lease comfortably exceeds normal processing time, then renew deliberately if processing may run longer ^[18].

The bridge across the send-and-commit boundary is a key derived from the logical delivery, such as `customerId + digestWeek + channel`, stored before sending and passed to a provider that honors idempotency when one is available ^[20]. Where the provider does not, the post recommends a delivery ledger that makes duplicates observable, and warns against pretending a local `sent` boolean creates exactly-once behavior across a network call ^[21]. The outbox record is inserted in the same transaction that makes a digest eligible; a dispatcher claims outbox rows, sends them, records the result, and publishes to the queue from the outbox if a queue is part of the design ^[22].

The queue's job shrinks to match. Publish only a job identifier, and verify the current database state when the worker receives it ^[9]. Keep the customer activity check close to the claim or send transaction, so an old queued message cannot revive an obsolete reminder ^[15]. A message scheduled six days ahead is awkward as the sole record when a customer changes time zone, becomes inactive, or opts out ^[8]. The post's own framing for all of this is authority versus transport ^[5].

Whether this transfers depends on conditions the post names. Being a few seconds late has to be less damaging than sending twice or silently skipping a week ^[6]. The context is a small team serving customers in Europe and the US, and the post says this is not the lowest-latency design ^[3]. On cost it declines to name a winner without request volume, database load, queue retention and operator time, and says the crossover "depends on the workload, not the product category" ^[12][13]. At sustained scale, it says, repeatedly scanning for sparse work may cost more than emitting delayed messages ^[12].