Skip to content

System Design Field Notes

System design is choosing where responsibilities live.

Every component should have:

  • A job.
  • Inputs.
  • Outputs.
  • Data ownership.
  • Failure modes.
  • Observability.

basic product shape

UserHas a job to complete.
FrontendTurns intent into structured input.
Backend APITrusted boundary and orchestration.
Business logicRules, permissions, workflows.
DatabaseDurable state.
Queue + WorkerBackground work and retries.
External serviceModel, payment, email, integration.
Logs and metricsEvidence from API and worker behavior.
  • What is synchronous?
  • What is asynchronous?
  • What data is durable?
  • What data is temporary?
  • What needs authentication?
  • What needs authorization?
  • What can be retried?
  • What must never happen twice?
  • What must be logged?
  • What must be auditable?
NeedPattern
User waits for immediate resultSynchronous API
Slow or unreliable workQueue plus worker
Avoid duplicate side effectsIdempotency key
Protect sensitive actionAuthorization check plus audit log
Fast repeated readsCache
Long file storageObject storage
Search by textSearch index
Human reviewPending state plus approval action

For each component, ask:

  • What if it is down?
  • What if it is slow?
  • What if it returns wrong data?
  • What if it returns partial data?
  • What if the user retries?
  • What if two users act at the same time?
  • What if the deploy changes schema before code is ready?
# Design
## Problem
## Users
## Current Workflow
## Proposed Workflow
## Components
## Data Model
## API Contract
## Failure Modes
## Security And Privacy
## Tests
## Deployment And Rollback
## Open Questions

You can explain the system at three levels:

  • User workflow.
  • Component diagram.
  • Request/data flow.