System Visualizations
Use these diagrams as starting points. Learners should copy the shape, then modify the labels for their own system. A useful diagram names components, boundaries, state, failure points, and evidence.
Request Flow
Section titled “Request Flow”user action to durable state
UserSubmits a ticket form.
BrowserValidates fields and sends JSON.
APIAuthenticates, parses, and validates.
ServiceApplies business rules.
DatabaseStores ticket and audit event.
UI StateShows success or useful error.
Component Map
Section titled “Component Map”typical product system
FrontendForms, navigation, display state, optimistic UI.
Backend APITrusted boundary for auth, validation, orchestration.
Business ServiceRules, permissions, workflows.
DatabaseDurable facts and queryable history.
Queue + WorkerSlow work, retries, background jobs.
External APIPayments, email, models, third-party systems.
CacheFast temporary reads, invalidation risk.
ObservabilityLogs, metrics, traces, alerts.
State Lifecycle
Section titled “State Lifecycle”object state over time
DraftUser can still edit.
SubmittedSystem has accepted the request.
In ReviewHuman or automated check is pending.
ApprovedWork can proceed.
CompletedOutcome and audit trail exist.
Rejected usually returns to DraftEvery transition needs permissionEvery transition should be auditable
Failure Boundary Map
Section titled “Failure Boundary Map”where bugs enter the system
Frontend stateBad validation, stale screen data, double submit.
HTTP boundaryWrong method, missing auth, wrong URL, timeout.
API boundaryWeak parsing, wrong status code, missing error body.
Business logicWrong rule, race condition, missing permission check.
DatabaseConstraint violation, migration mismatch, slow query.
Response pathWrong shape, hidden failure, misleading success state.
Data Lifecycle
Section titled “Data Lifecycle”what the system remembers
InputRaw request from user or integration.
ValidateType, shape, permission, business rule.
PersistStore the durable fact and owner.
DeriveCalculate views, status, metrics.
ExposeReturn contract-safe response.
AuditRecord who changed what and why.
SDLC To ADLC
Section titled “SDLC To ADLC”human-owned lifecycle with agent acceleration
ProblemClarify user workflow and success metric.
DesignMap components, data, risks, rollback.
Agent taskDelegate a bounded slice with context.
BuildImplement the smallest useful change.
VerifyRun tests and inspect runtime behavior.
ReviewHuman checks diff, claims, and assumptions.
DeployRelease with rollback and observability.
LearnUpdate docs, next task, and evidence.
Deployment And Rollback
Section titled “Deployment And Rollback”release path
BuildPackage source into a versioned artifact.
ConfigureInject environment, secrets, feature flags.
DeployRoll out to a small blast radius first.
Smoke testCheck the real user path and health.
ObserveWatch logs, metrics, traces, tickets.
RollbackReturn to the previous known-good version.
Observability Triad
Section titled “Observability Triad”evidence during incidents
LogsSpecific events.
- request id
- user id
- error reason
MetricsSystem trends.
- latency
- error rate
- queue depth
TracesOne request path.
- frontend
- API
- database
Agent Verification Loop
Section titled “Agent Verification Loop”do not accept agent output without proof
ContextGive files, goal, constraints, expected output.
TaskMake the agent do one bounded job.
ReviewCheck diff, assumptions, invented APIs.
VerifyRun tests, build, browser/API checks.
IntegrateAccept, revise, or reject with notes.
How To Use These
Section titled “How To Use These”For every feature, create at least three diagrams:
- Component map.
- Request or data flow.
- Failure boundary map.
For every release, add:
- Deployment and rollback path.
- Observability evidence.
- Agent verification loop if an agent touched the work.