AP3
All topics

Structure / mapping ownership before adding capability

Systems Design

Design the agreements that let a product stay coherent as it grows.

Why this matters

Polish depends on seams: data, permissions, state, failure, and the language between systems. Systems design makes those seams visible enough to preserve product intent.

Concepts to learn

  • Canonical data ownership
  • Bounded contexts
  • State and failure models
  • Permissions
  • Performance and scaling

Apply It in Casset

Casset is the working environment for this skill—not the curriculum itself.

  • Map the canonical owners across Profile World, Artist Runtime, Track Runtime, playback, permissions, and analytics.
  • Identify one duplicated or transitional bridge and propose a migration that preserves behavior.
  • Document what a new surface projects from existing owners rather than recreates.

Suggested project

Ownership map

A readable system map of the product nouns, owners, projections, and failure boundaries.

Evidence of completion

These are completion conditions, not claimed achievements. Each stays planned until it links to a real artifact or verification.

  • diagramA canonical ownership diagramplanned
  • pull requestOne duplication removed or boundary clarifiedplanned
  • reflectionA tradeoff noteplanned

Open questions

  • Which boundaries should remain stable while the product changes?
  • How much architecture is enough to prevent drift without freezing the idea?

Related notes

Books, talks, and useful things

  • book
    Designing Data-Intensive ApplicationsMartin Kleppmann

Reflection journal

The system is part of the concept's credibility, not the work that begins after the concept.