Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
John asks Anna to design BlueTicket's complete payment flow — from a fan pressing "Pay" to the ticket in their inbox — including every way it can fail, so that no fan is ever charged without a ticket and no fan is ever charged twice.
The pieces: BlueTicket's API and database, the payment provider's API (with idempotency keys, webhooks and a list-payments endpoint), a message queue with workers, and the email provider.
What Your Design Needs
- List the steps of the happy path in order, and say which are synchronous (inside a request) and which are asynchronous (via a queue).
- Explain how BlueTicket calls the payment API safely: authentication, timeout, retries, and how double charges are prevented.
- Describe the webhook handler: what it checks, what it stores, and how fast it replies.
- Explain how duplicate webhooks are handled, and how a completely lost webhook is recovered.
- List at least four failure cases (for example: card declined, provider timeout, provider down, email provider down, seat hold expires before payment) and what happens in each.
- Say how the team would know if something is going wrong.
Stuck? A Few Hints
- Draw it first: fan, BlueTicket, payment provider, queue, worker, email provider.
- For every arrow, ask: what if this message is slow, duplicated or lost?
- The seat hold from Act 08 and the transaction from Act 13 still matter here.
Before You Move On
The happy path is the easy part — every developer can draw it. The professional part is every arrow's 'what if': slow, duplicated or lost. If your design answers those, no paid order gets lost, and no fan pays twice.