One discipline · five design lenses

Choose the system boundary. Then choose the method.

System design can mean a global backend, a processor and memory hierarchy, a real-time device, an entire multidisciplinary mission, or an analog AI accelerator. Start with what you are responsible for designing.

Choose a track Open the decision map →

5design tracks
50+visual models
7interview prompts

choose-boundary.md

# The word “system” is contextual
boundary = identify_responsibility()

if boundary == "services + data":
    track = backend_distributed
elif boundary == "whole engineered product":
    track = systems_engineering
elif boundary == "compute platform":
    track = hardware
elif boundary == "physical feedback loop":
    track = embedded
elif boundary == "analog AI accelerator":
    track = npu_acim

state_requirements_and_tradeoffs()

01 · Track selector

What are you designing?

Each track shares systems thinking, but its constraints, artifacts, bottlenecks, and interview language are different.

System boundaryWhich elements are inside your responsibility?

01 · Software services

Backend & Distributed

APIs, data stores, caches, queues, consistency, availability, traffic and operations.

Example: design a global news feed → 02 · Whole product

Systems Engineering

Stakeholders, ConOps, requirements, allocation, interfaces, risk, integration and V&V.

Example: design an autonomous drone → 03 · Compute platform

Hardware & Computer

Workloads, microarchitecture, memory, interconnect, PPA, thermal and reliability.

Example: design an edge AI computer → 04 · Physical control

Embedded & Cyber-Physical

Sensors, firmware, real-time deadlines, control, power, safety and actuators.

Example: design a smart camera → 05 · Analog AI compute

NPU Software Stack · ACiM

Graph compiler, analog-aware mapping, runtime, calibration, drift and digital fallback.

Example: design a hybrid ACiM NPU →

02 · Shared reasoning engine

Every track follows the same evidence loop

The artifacts change, but good designs always connect stakeholder need to a verified and operable solution.

01Need
Who succeeds, under what operating scenario?
02Requirements
Make functions and quality constraints measurable.
03Estimate
Size load, data, timing, energy and environment.
04Decompose
Break behavior into functions and interfaces.
05Allocate
Assign functions to services, hardware, software or people.
06Trade
Compare alternatives with explicit criteria.
07Realize
Implement and integrate from components upward.
08Verify
Prove the design meets its requirements.
09Validate
Prove the system solves the intended need.
10Operate
Observe, recover, evolve and eventually retire.

Reasoning sentenceBecause requirement R and estimate E expose constraint C, choose architecture A, accepting trade-off T, verified by measure M.

Standards + protocolsDefine the contract

Use exact semantics and compatibility rules from sources such as RFC 9110, then state which revision and subset the design implements.

Foundational researchKnow the assumptions

Papers such as Roofline explain a model and its boundary; they do not replace workload-specific measurement.

Official implementation docsClose ownership details

References such as the Linux DMA guide turn “move data” into mappings, direction, synchronization, barriers, and cleanup.

Measured evidenceProve this configuration

Use representative load/fault tests, calibrated equipment, raw traces, versions, and acceptance criteria. The NASA SE Handbook is a useful evidence-planning anchor.

Reference rule · audited 2026-07-19: every detailed track links sources beside the decision they support. A URL containing current or latest is a living document, not a reproducible revision: record the exact product, standard, library, or manual version and the date checked in a real decision log. Treat examples and Atlas schemas as illustrative; applicable safety obligations, silicon manuals, and measured target behavior remain authoritative.

03 · Discipline decision graph