Why this matters
The backend determines what an interface can promise. Understanding it makes performance, permissions, migrations, observability, and failure part of product design rather than invisible implementation detail.
Concepts to learn
- API design and database modeling
- Migrations and rollback procedures
- Authentication, authorization, and server-side permissions
- Caching, rate limiting, and idempotency
- Webhooks and background jobs
- Structured logging and request tracing
- Error taxonomies, health checks, and recovery
Apply It in Casset
Casset is the working environment for this skill—not the curriculum itself.
- Trace the public artist API's intentional fail-closed `503`, document why it is correct today, and design the distributed rate-limit and availability path required to graduate it.
- Turn the historical Shelf migration failure into a smoke check and incident note; preserve the current healthy path while distinguishing empty data from request failure in the UI.
- Extend the existing `x-request-id` discipline from the Headless API across a second important request path.
- Verify webhook replay safety, canonical permission enforcement, and one migration/rollback procedure with tests or a rehearsal.
Suggested project
Public path reliability notebook
Trace, diagram, test, and verify one public request from route to persistence to visible recovery.
Open project notebookEvidence of completion
These are completion conditions, not claimed achievements. Each stays planned until it links to a real artifact or verification.
- diagramRoute → service → database → response → UI request traceplanned
- testsContract, permission, idempotency, or smoke coverage for the chosen pathplanned
- incidentA concise Shelf incident and recovery write-upplanned
- productionHealth and request-correlation verification against productionplanned
Open questions
- Which failures should fail closed, fail soft, or become an explicitly degraded product state?
- How much infrastructure should a small consumer product own before the operational cost changes the bet?
Related notes
Books, talks, and useful things
- bookDesigning Data-Intensive ApplicationsMartin Kleppmann
- toolPostgreSQL
Learn against real constraints, real migrations, and recoverable mistakes.
Reflection journal
Following one request all the way through the system makes the interface less abstract and the promise more honest.