Foundation
Essential view of the system and decision
Core components and one primary system boundary.
Practice real engineering decisions.
Work through realistic system problems. Compare designs, test assumptions, and revise when the evidence changes.
Workbench
System: Checkout
Draft v0.3 · Last saved 2m ago
- Web to API Gateway
- API Gateway to Order Service
- Inventory Service to Redis
- Notification Service to Email Provider
Linked reasoning
- Why Postgres for orders?DEC-007
- Why Redis for cart state?DEC-011
- Why sync inventory?DEC-015
- Why email provider (SES)?DEC-019
Coach
What's the highest-risk assumption in this design?
Your answer…
Save responseFocus
Reliability under traffic spikes
Constraints
99.9% availability, < 250ms p95 latency
Risk watch
High · inventory consistency
Production constraints
A working implementation is only the start.
Production adds traffic, failures, security requirements, cost limits, and incomplete information. You still have to decide what the system should optimize and what it can trade away.
03 · Decision record
Connect the design to the reason.
Record each important choice with its constraint, assumption, evidence, and consequence.
Trace · DEC-011
Decision example
Keep cart state in Redis
Choose the problem. Choose the support.
Select a scenario by technical area and complexity. Then choose how much guidance stays visible while you work.
Depth and guidance
Scenario complexity and guidance are separate settings. Neither is a rank or score.
You can change these at any time.
1 — Choose scenario depth
Pick the complexity of the problem you want to solve.
Standard
Service boundaries and data flows
Additional services, data flows, and failure paths.
Advanced
Cross-cutting concerns and external context
Includes integrations, security, and operational concerns.
2 — Choose guidance level
Control how much of the process stays visible while you work.
Guided
Stage guidance and prompts remain visible.
Balanced
Essential structure stays visible; optional prompts stay out of the way.
Independent
Only stage requirements and completion checks remain visible.
Guidance changes what the interface shows, not how your work is evaluated.
Review how your decisions changed.
Each completed practice preserves the decision, evidence, critique, and revision. Review the record later or apply the same reasoning to a follow-up.
Decision history, not a score
01 · First pass
The initial decision and its context.
May 07 · 09:12
Decision
Use Postgres for orders to keep write paths simple.
Context
Early decision to minimize moving parts before launch.
Notes
Chose familiarity to reduce risk under time pressure.
02 · After critique
What changed and why.
May 07 · 11:03
Critique
“Write path will couple hot orders with reporting and exports.”
Why it matters
Shared database creates noisy-neighbor risk as data and queries grow.
Evidence
Load test: concurrent inserts + reporting query caused p95 spikes.
03 · Revision
The change made after critique.
May 07 · 11:40
Revision
Route writes through the Inventory Service.
What changed
Isolated write path; reporting reads from replicas.
Reasoning shift
From “simplest to start” → “simplest to scale safely”.
04 · Transfer
The same reasoning in a new context.
May 08 · 10:18
Transfer
Applied the same boundary pattern to Notifications.
New context
Different domain, same coupling-risk pattern.
Insight carried
Define the write boundary first; let other concerns follow.
Practice recordDecision, critique, revision, and follow-up.No score or level is assigned.
06 Data boundaries
Practice with fictional systems.
After Syntax does not need company code, customer data, internal documents, or confidential architecture details.
01
Built for practice
Each assignment uses a fictional organization and system.
02
Stored with your account
Your learning work stays with your account until you delete it.
03
Exclude real work data
Do not paste code, customer records, credentials, or internal documents.
Use only fictional or sanitized information.
Practice your next engineering decision.
Choose a realistic assignment, make the tradeoffs explicit, and test what happens.