APIs, Services & the Capstone
A track of P38 · Architecture, Services & Distribution.
Design a service other code calls across: an in-process API with a request/response contract, idempotency (safe retries) and versioning - capped by a project capstone that builds a resilient, idempotent service over an injected port.
A service is a boundary other code calls across. This track designs one — and caps the pillar with a capstone that ties architecture, idempotency and resilience together. Everything is built and tested in process (request in, response out, no socket); real serving stays prose.
You start by building an in-process API over a request/response contract with
honest status codes, then get its two hardest details right: idempotency (an
idempotency key so a retried POST creates once — the only way retries are safe over
an unreliable network) and versioning (a /v1 prefix so the contract can evolve
without breaking clients — the packaging discipline from P35, applied to a running
service). The capstone then asks you to build a small resilient order service:
it depends on an injected persistence port, is idempotent by key, and retries a
flaky store with backoff — surfacing a permanent failure rather than dropping it.
It's graded by hidden tests and a design rubric, and it's the kind of service you'd
package (P35), CI-gate (P36) and observe (P37): the production discipline end to end.