APIs
APIs: design and build a production API
Reading the cascade is not the same as building something that survives it. Design and ship a small public API where every decision load-bears the next — model the nouns, make the status codes an honest retry contract, paginate by cursor, lock the shape in a spec-first contract with a CI break diff, and gate it with a rate limit — then prove each link holds under a retry storm.
Turn the whole track into one coherent build: a production-grade API whose resource model, status codes, pagination, contract, and rate limit are designed together, with tests and a load run that demonstrate the seams between them do not fail.
Design and build a small but production-grade public API for one domain (e.g. payments, orders, or a content feed) where resource modeling, status codes, cursor pagination, the OpenAPI contract, and rate limiting are all designed as one connected system — then prove the chain holds under a retry storm with before/after evidence.
- An automated test proves idempotency: two identical POSTs with the same Idempotency-Key produce exactly one resource and the second returns the original result, not a duplicate.
- An automated test walks cursor pagination through inserts: paging the list while new rows are inserted neither skips nor duplicates rows, and deep pages cost the same as the first.
- The CI break-diff job is demonstrated both ways: an additive change passes the build and a breaking change fails it, with the diff output captured.
- A load run shows the rate limit working: over-quota requests get 429 + Retry-After (not silent drops or 500s), and a simulated retry storm against an unsafe write produces no duplicate side effects (idempotency + throttle together).
- A one-page write-up traces the cascade through your API: which modeling decision made which status code possible, and which guardrail (contract, pagination, rate limit) protects which downstream failure.
- Add a versioning demonstration: ship an additive change to /v1 with no bump, then a genuine break behind /v2 (or a media-type version) with Deprecation and Sunset headers per RFC 8594/9745, and keep v1 alive.
- Add a gRPC internal service behind the REST edge for one high-volume operation and benchmark it against an equivalent REST call, showing where the protocol split actually pays off.
- Add contract testing in CI (e.g. provider verification against the OpenAPI spec or a consumer-driven contract) so the running server cannot drift from the spec without failing the build.
- Add observability: structured logs of 4xx/5xx rates, 429 counts, p99 latency, and a dashboard panel that would let an on-call engineer spot a retry storm before it becomes an outage.
This is the build behind every real public API: nouns first so status codes can be honest, an Idempotency-Key and the right codes so retries are safe, cursor pagination so large/live reads stay flat and stable, a spec-first OpenAPI contract with a CI break diff so drift cannot ship silently, additive versioning with a Sunset policy for real breaks, REST at the edge with gRPC reserved for internal volume, and a 429 + Retry-After rate limit so load cannot become an outage. Building it once as one connected system — and proving the seams under a retry storm — is what turns the track’s mental model into production muscle memory.