System Design Atlas

A visual, interview-oriented guide to five related design disciplines:

• Backend and distributed systems
• Formal Systems Engineering
• Hardware and computer systems
• Embedded and cyber-physical systems
• NPU software stacks for Analog Compute-in-Memory (ACiM)

The Atlas uses flowcharts, decision maps, trade-off matrices, bottleneck catalogs, worked calculations, and revealable interview coaching. Its visual language matches the companion DSA Atlas.

1. Choose the page that matches the system boundary—not merely the job title.
2. Follow the page’s reasoning flow: clarify outcomes, make assumptions visible, estimate the first-order budgets, draw the critical path, choose a design, and close with failure handling and evidence.
3. Open Interview mode for the track’s 45–55 minute timer, nine interview checkpoints, hidden coaching, and a five-part self-score.
4. Work the quantitative example before opening the coaching notes.
5. Use the bottleneck matrix to pressure-test the proposal and the evidence table to turn claims into measurable pass/fail criteria.

The worked numbers are deliberately labeled as illustrative assumptions. Recalculate them for the prompt, state the unit and measurement boundary, and distinguish average values from tail targets.

• index.html — track selector, shared reasoning loop, and an integrated autonomous-drone case spanning all five tracks
• backend.html — scalable software and distributed systems from interview framing through launch, operation, evolution, and retirement
• systems-engineering.html — needs, requirements, allocation, coupled budgets, architecture search and optimization, trade decisions, risk, integration, statistical evidence, transition, operation, sustainment, and retirement
• hardware.html — workload-driven architecture, implementation sign-off, ordered bring-up, qualification, production release, sustainment, and retirement
• embedded.html — real-time and cyber-physical design through characterization, integration, V&V, commissioning, update/recovery, and safe decommissioning
• npu-acim.html — ACiM NPU compiler/runtime stack from intended-use framing and target characterization through qualification, fleet release, operation, and retirement

The shared Atlas contract has 12 ordered phases: need, requirements, estimate, decompose, allocate, trade, realize, integrate, verify, validate, transition, and operate/evolve/retire. Each track adapts that contract to its design object instead of forcing identical vocabulary or pretending the work is a one-way waterfall.

Risk and safety, security and privacy, configuration and interface control, evidence and traceability, cost, and operability are continuous controls. They are reassessed throughout the lifecycle rather than appended as late cleanup phases.

The repository enforces each primary phase flow as an ordered, counted contract in both the static validator and browser suite. This guards against accidentally dropping integration, proof, transition, operational ownership, or retirement when the interview content evolves.

The site has no runtime dependencies. Development and validation require Node.js 24 or newer. Install the locked development tools first:

npm ci

npm run serve

Open http://127.0.0.1:43129/. To use another port, set the PORT environment variable before starting the server.

Build the exact public artifact:

npm run build

This recreates _site/ from an explicit allowlist. Repository metadata, scripts, and workflow files are not published.

Regenerate the six route-specific 1200 × 630 social-preview cards after changing their copy or visual model:

npm run generate:social

Run the fast static checks:

npm run check

The check command syntax-checks all browser and repository scripts, runs deterministic calculation and security-boundary tests, rebuilds _site/, validates the source content, and confirms that the artifact contains only the intended public files with byte-for-byte matching content.

For browser smoke tests, install Chromium once and run Playwright:

npx playwright install chromium
npm run test:ui

The site validator checks all six pages, internal files and fragments, shared navigation, interview controls, diagram expansion, table scroll cues, route-specific preview metadata, encoded attributes, source anchors, core calculation sentinels, accessible table contracts, responsive CSS tokens, contrast, the packaged artifact, and pinned Pages workflows. A separate scheduled workflow checks external references weekly. Access-controlled, rate-limited, timeout, and transient gateway/service responses are reported as inconclusive; persistent HTTP 500, DNS, TLS, and other deterministic connection failures fail the check.

Detailed sections link sources beside the decision they support. The Atlas favors standards, official implementation documentation, foundational papers, and published measurement evidence, including:

• NASA Systems Engineering Handbook
• NASA Design Solution Definition and NASA Decision Analysis
• SEBoK System Analysis
• NIST experimental-design selection
• HTTP Semantics, RFC 9110 and HTTP Caching, RFC 9111
• Linux DMA API HOWTO
• Roofline: an insightful visual performance model
• ONNX IR, MLIR dialect conversion, and CiMLoop

Sources explain a model or contract; they do not prove a particular design meets its requirements. A real project still needs configuration-controlled assumptions, current product specifications, representative load/fault tests, calibrated measurements, and explicit acceptance criteria.

Reference availability was reviewed on 2026-07-26. Links containing current or latest intentionally follow living documentation; record the exact applicable revision and access date when using one in a design decision.

• Repository: https://github.com/buicongnguyen/SystemDesign
• GitHub Pages: https://buicongnguyen.github.io/SystemDesign/

Like the companion DSA Atlas, pull requests run static and browser validation, and pushes to main publish the allowlisted static artifact through GitHub Actions.

See CONTRIBUTING.md for the evidence, accessibility, and validation expectations used for changes. Please report suspected vulnerabilities according to SECURITY.md, not in a public issue.

The repository uses separate licenses by material type:

• Source code, styles, automation, and configuration are available under the MIT License.
• Original educational prose and diagrams in the HTML pages are available under the Creative Commons Attribution 4.0 International License.

See the standard MIT code license and the educational-content license for exact scope and attribution guidance. Third-party works remain under their respective owners' terms.