The setting

Quillpay processes seller payouts for online marketplaces: a marketplace sends instructions, Quillpay moves the money to sellers' banks. You are a backend engineer on the payouts platform team, where correctness is measured in other people's money.

Every mission on this path happens at the same company, so context carries over the way it does in a real job: the data you cleaned in mission two is the data the finance lead questions in mission four.

The missions

1. API contractstarter

Review the payouts API draft before partners build against it

Quillpay's draft payouts API goes to three marketplace partners next week, and once partners write code against a contract, every flaw becomes permanent. The draft was written in a hurry during a proof of concept and has never had a contract review.

You deliver: A contract review of the payouts API draft with a corrected contract sketch.

Scored on: Money type fixed, Idempotency required, Error semantics, Consistency and scale.

Working from: payouts_api_draft.md.

2. data modelstarter

Fix the payout schema before the duplicates get worse

Support has confirmed three duplicate payouts this quarter, 2,703.45 paid out twice in total, and clawing money back from sellers' bank accounts is slow and embarrassing. Every duplicate traces to the payouts table happily accepting the same marketplace instruction twice. The schema needs review before volume doubles...

You deliver: A data model review with a revised payouts table design whose constraints prevent duplicate payouts at the database level.

Scored on: The uniqueness fix, Money and status typing, Auditability restored, Complete revised design.

Working from: payouts_schema.md, support_cases.md.

3. auth boundarycore

Close the holes in Quillpay's service boundary

A routine log review found an IP address outside Quillpay's network calling an internal admin endpoint that can re-send payouts. Nothing bad has happened yet, as far as anyone can tell. Security asked platform for a full authentication and authorization review of the payout service's surface before the quarterly audit.

You deliver: A ranked auth boundary assessment of the payout service's routes with per-route fixes and immediate containment actions.

Scored on: The replay endpoint, Credential leakage, Webhook forgery, Ranking and containment.

Working from: endpoint_inventory.md, access_log.md.

4. queue designcore

Design the webhook retry queue that will not melt again

On April 2, a partner's webhook endpoint went down for 40 minutes and Quillpay's delivery system turned the outage into a three-hour incident: every pending delivery retried in lockstep every 5 seconds, hammering the partner the moment they recovered. The postmortem's top action item is yours: design the replacement...

You deliver: A queue design document for webhook delivery covering backoff, dead-lettering, ordering, isolation, and replay.

Scored on: Backoff with jitter, Retry budget and DLQ, Ordering under retries, Isolation and replay.

Working from: incident_report.md, current_config.md.

5. observabilitystretch

Instrument payouts so the next silent failure lasts minutes, not 94

On May 12, an expired certificate broke Quillpay's connector to one bank at 03:10. Every payout to that bank failed silently until 04:44, when a partner emailed. Detection took 94 minutes, diagnosis took three more hours, and the postmortem's finding was blunt: the system emits almost no signal about the thing it...

You deliver: An observability plan with SLIs, alert thresholds validated against the May 12 incident, a correlation logging scheme, and dashboards.

Scored on: SLI definitions, Alerts validated against May 12, Correlation across services, Pragmatic sequencing.

Working from: postmortem.md, current_signals.md.

How the scoring works

Each deliverable is graded against the rubric written for that mission. Separately, every mission on every path is graded on how you used AI, against the same four criteria:

  • Understood the task. The learner framed the goal for the assistant clearly instead of pasting the brief and hoping.
  • Grounded in the material. The learner directed the assistant into the provided files and based the work on them, not on invented facts.
  • Verified the output. The learner checked claims, numbers, or coverage against the source material before submitting.
  • Iterated with judgment. The learner refined weak parts of the draft with specific follow-ups rather than accepting the first answer.

Both scores, with the work behind them, go on your proof profile. That is what makes a claim like "I can use AI for backend engineering" something an employer can check.