My path
Five phases, in order. Each module states why it is here and what it was built from.
OrbitPay demo data. Connect your sources to generate this from your own repositories, Slack, and Linear.
About 4 hours of guided work, then a real issue.
What the company does and how this team contributes to it.
Basis points on settled volume, not attempted volume. This is why reliability work in the retry path is revenue work.
Why this module: Every payments engineer needs the settled-versus-attempted distinction before any incident history makes sense.
Three repositories, one shared ledger, and the ownership boundaries that decide who reviews your pull request.
Why this module: Maya's first contribution will land in payments-worker, so she needs to know it is single-owner before she picks a reviewer.
The architecture, the main data flow, and who owns what.
Why the API never talks to a processor directly, and what that buys you when a processor degrades.
Why this module: The boundary between checkout-api and payments-worker is the single most load-bearing design decision in Maya's target repositories.
Follow one request from the storefront to the ledger, with the code and the conversations that explain each hop.
Why this module: PAY-231 touches the retry scheduler. Maya cannot evaluate a scheduling change without first seeing where scheduling sits in the request path.
The decisions and incidents that made the system look like this.
A 90-second processor blip took checkout down for 34 minutes. Rebuild the causal chain from the incident thread and the fix.
Why this module: PAY-184 is the reason the retry scheduler looks the way it does. It is the highest-value single piece of history for this role.
Full jitter, the exponential ceiling, and the dedupe gap that PAY-231 is about to close.
Why this module: Directly precedes the starter issue. Maya needs the current behaviour in her head before she changes it.
Where understanding gets demonstrated instead of assumed.
You get the logs, the code, and the Slack thread. Find the root cause and propose a fix.
Why this module: Reading about PAY-184 is not the same as diagnosing it. This is where readiness is measured rather than assumed.
A real issue, with the context needed to ship it.
Prevent duplicate retry scheduling. Two files you have already read, existing tests, low production risk.
Why this module: Smallest surface area of any open issue that still touches the subsystem Maya just learned, and it has test coverage already.