Design Scheduled Messages

Problem Statement: Scheduled Messaging at Scale

Design scheduled messaging for products like Slack, Telegram, or LinkedIn, where a user writes a message now and expects it to appear later exactly when intended. This is not a cron-job wrapper around send-message. It is a durable workflow with user-visible trust requirements.

Core contract

A scheduled message has an author, destination, payload reference, send time, timezone display rule, editable window, cancellation rule, and audit trail. The system must preserve the user's intent even when workers restart, regions fail over, or the downstream messenger is temporarily unhealthy.

What makes it tricky

• The author can edit or cancel before dispatch, but not after the dispatch lease is acquired.
• The send path must reuse the normal messenger pipeline so delivery, moderation, and receipts stay consistent.
• Retries are required, but duplicate visible sends are unacceptable.
• Timezone display is client-facing; execution should use server-owned UTC time.

Why interviewers care

Scheduled Messages interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

The failure that defines the design

The outage to narrate is the message that fires hours late or twice. A user schedules a birthday note for 9:00am; the scanner falls behind or the worker holding it dies, and it goes out at noon — or worse, a retry without idempotency sends it twice. Both are visible, embarrassing failures of the one promise the feature makes: send this exactly once, at the right time. The fix is the spine of the design: persist the scheduled message durably, find due items with a time-bucketed scan rather than a full-table sweep, and dispatch through an idempotent claim-and-send so a crashed worker's items are re-leased and the hand-off to the messenger dedups. State durable scheduling plus time-bucketed due-detection plus idempotent dispatch up front, because punctual and exactly-once is the whole product.