Short answer
System design defines how to assess technical boundaries, interfaces, data flow, and failure choices at increasing scope.
About System design
The ability to shape system structures and boundaries that meet current needs while allowing safe operation and change.
Use this competency for
- Roles that make decisions about components, interfaces, data, or distributed workflows.
- Functions where technical choices create dependencies for other teams.
Do not use this competency for
- Work limited to using established systems without changing their boundaries or contracts.
Important distinctions
Code quality
Code quality concerns the maintainability of code. System design concerns boundaries and interactions among components.
Reliability engineering
Reliability engineering targets availability and recovery outcomes. System design covers the wider structure, including but not limited to failure behavior.
Expectations by level
IC1
Individual contributor 1
Changes a well-bounded component with guidance, follows existing design patterns, and checks assumptions before affecting a shared interface.
Observable behaviors
- Traces the relevant data or request path before changing it.
- Uses the established boundary for a scoped change.
- Requests design review before altering a shared contract.
Examples
- Added a field through the existing interface without exposing internal storage details.
- Mapped the callers of a component before changing its response shape.
IC2
Individual contributor 2
Independently designs a team-level change with incomplete requirements, resolving interface, data, and failure trade-offs.
Observable behaviors
- Documents the chosen boundary and rejected alternatives.
- Plans migration and rollback for a stateful change.
- Validates contracts with affected component owners.
Examples
- Designed an asynchronous workflow after comparing retry and duplication behavior.
- Introduced a staged data model change that kept existing readers working.
IC3
Individual contributor 3
Frames ambiguous design problems across teams, sets direction for shared boundaries, and enables teams to implement compatible solutions independently.
Observable behaviors
- Defines ownership and contracts across multiple components.
- Reviews designs for coupling, operability, and change cost.
- Turns repeated design choices into a reusable standard.
Examples
- Defined a shared event contract that three teams implemented without conflicting assumptions.
- Separated a tightly coupled workflow into owned boundaries with an agreed migration sequence.