Design it. Implement it. Prove it. 5 problems

A notification delivery service that evolves across four stages: devices + fan-out → preferences + cancellation → bounded concurrent delivery → retry/invalid-token/expiry. The make-or-break is Stage 3: fan out to a large audience fast without ever exceeding the provider's concurrency ceiling or leaking a permit when a send throws.

An inventory reservation service that evolves across four stages: stock + reservations → confirm/cancel with idempotent states → no overselling under contention → time-based expiry. The invariant supplied = available + reserved + sold must hold after every transition and every concurrent request. Stage 3 is the make-or-break: a flash sale of 100 units must never sell 101, no matter how many buyers race.

A durable background job queue that evolves across four stages: enqueue/ack → retries with backoff → worker leases under concurrency → dead-letter + idempotency. The hard part is ownership: a lease grants temporary, exclusive ownership, and Stage 3 is the make-or-break — two workers must never both believe they own the same live job.

An idempotent payment processor that evolves across four stages: payment state machine → response replay on retry → safe under concurrent duplicates → transactional outbox. Each stage closes a specific double-charge or lost-event window that the previous version leaves open. The make-or-break is Stage 3: one logical request must invoke the gateway at most once, even when 100 retries land at the same instant.