Every order must trigger an action exactly 30 minutes after it is placed, for millions of orders a month. How would you weigh EventBridge Scheduler one-time schedules against the other AWS ways of building that timer?

## The shape of the problem "Do something per entity, later" is one of the most common designs interviewers probe, because every option is defensible and the reasoning is what is being graded. State the axes first, then place the options on them. **Precision** — must it fire at 30 minutes, or is a window acceptable? **Cancellation** — orders get paid, cancelled or amended, so most timers must be revocable by identity. **Scale ceiling** — how many timers are live at peak, and what quota or table growth does that imply? **Cleanup** — who removes a timer that has fired or been superseded? **Cost and ops surface** — per-timer charges, and how much code you own. ## Option 1: EventBridge Scheduler, one schedule per order Create an `at()` schedule when the order is placed, named deterministically from the order id, with `ActionAfterCompletion=DELETE` so it removes itself after firing. Cancellation is a `DeleteSchedule` call by that name; rescheduling is an update. Strengths: exact firing time; per-schedule IAM role, retry policy and dead-letter queue so a failed invocation is visible and redrivable; time-zone support if the deadline is expressed in local terms; no infrastructure of yours in the path. This is the option Scheduler was built for — its schedules-per-account quota is in the millions rather than the hundreds that constrained scheduled rules. Costs and cautions: an API call per order on the write path, so the order service now depends on Scheduler's availability — decide whether a failed `CreateSchedule` fails the order or is retried asynchronously. The quota is per account and region, so model *live* timers (30 minutes of order rate, not monthly volume) and check the current figure in Service Quotas rather than trusting a remembered number. And if you ever forget `ActionAfterCompletion`, completed schedules accumulate against that quota. ## Option 2: SQS delayed message Send a message with a delivery delay when the order is placed and let the consumer act when it arrives. Cheap, dead simple, no cleanup. It fails this requirement on two counts. SQS's per-message delay maxes out at 15 minutes, so 30 minutes needs chaining or a re-drive trick — a smell. And you cannot cancel a specific in-flight message; the consumer must re-check the order's current state and no-op if the action is no longer wanted. That state check is mandatory anyway in every option, but here it is the *only* defence, which means a stale timer always does a wasted read. ## Option 3: Step Functions workflow per order Start a Standard workflow at order creation with a wait state, then the action. Standard workflows can wait a very long time, and the workflow can be stopped by execution name when the order changes. This wins when the timer is one step of a larger process — wait, check, retry, escalate, compensate — because you get the whole orchestration, plus per-execution history for free auditing. It is heavier when the timer is *all* you need: one execution per order, priced per state transition, and an execution history to manage. The honest rule is that a wait state should ride along with real orchestration rather than exist for it. ## Option 4: your own timer table Store a due timestamp on the order (or in a timers table) and sweep it on a schedule — a single recurring job querying "due before now". Cheapest per timer by a wide margin, cancellation is a row update, and there is no external quota. You own everything else: the sweep interval sets your precision floor, the query needs an index that supports it, and the sweeper needs idempotency and leader-ish behaviour so two runs do not double-fire. DynamoDB's TTL is sometimes proposed here — do not use it as a timer. TTL deletion is best-effort and can lag well past the expiry time, so it is fine for reclaiming space and wrong for anything with a deadline. ## How I would actually decide If 30 minutes must be 30 minutes and the action is a single step: Scheduler one-time schedules, named by order id, self-deleting, with a dead-letter queue on the schedule. If the 30-minute wait is one beat of a longer saga: Step Functions. If the tolerance is loose, volume is extreme, and cost dominates: the sweeper, accepting that you now own a piece of infrastructure. Two things I would insist on regardless. **The handler must be idempotent and must re-read current state** — every timer mechanism can fire late, twice, or after the reason for it has evaporated, so the timer is a hint to check, never an instruction to act blindly. And if a large cohort of timers can land at the same instant — everything placed during a flash sale — the flat spike is a real risk; Scheduler's flexible time window spreads it when precision permits, and a sweeper naturally batches. ## The trap in the question The phrase "millions a month" invites a quota panic. Convert it: what matters is concurrent live timers, which for a 30-minute delay is thirty minutes of arrival rate, a much smaller number. Making that conversion out loud is most of the answer.