Foundation
Essential view of the system and decision
Workbench
System: Checkout
Practice the decisions code can't make.
Build the judgment to make tradeoffs, explain your choices, and see what holds up.
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
The hard part starts after it works.
Reliability, cost, security, and change all arrive at once. The code can pass while the decision behind it is still fragile.
When the happy path ends
Traffic spike
What happens when traffic doubles without warning?
Consistency
Will every service see the same data, in the same order?
Cost boundary
Where does usage cross from predictable to expensive?
See the system differently.
Move beyond boxes and arrows. Connect the choice, the reason, and the consequence.
Open reasoning ledger
Trace · DEC-011
Reasoning, made visible
Practice that meets you where you are.
⋮
Standard
Service boundaries and data flows
Workbench
System: Checkout
Advanced
Cross-cutting concerns and external context
Workbench
System: Checkout
Start with the problem that fits. Choose how much of the process stays visible.
Change either choice for your next scenario.
Guidance (your choice)
Guided
More process shown, more prompts
Balanced
Right amount of structure and space
Independent
Fewer prompts, more open canvas
See your thinking get sharper.
Show qualitative growth through a real work trail, never a score or mastery claim.
The work becomes the evidence
First pass
Where the thinking started.
Decision
Use Postgres for orders to keep write paths simple.
Unresolved risk
Multi-region write conflicts are not clear yet.
After critique
What changed and why.
Revision
Route writes through the Inventory Service.
Evidence
Load test: queue smoothing avoids hot-spot contention.
What carried forward
Where this thinking showed up next.
Transfer
Applied the same boundary pattern to Notifications.
New context
Different domain, same reasoning.
Keep the trail of what you chose, what changed your mind, and what you carried into the next system.
Practice freely. Keep real systems private.
After Syntax gives you realistic fictional systems to explore—without asking for company code, customer data, or confidential designs.
01
Fictional by default
Every scenario is made for practice.
02
Private by design
Your work stays in your session.
03
Leave real data out
Protect company and customer information.
If it belongs to work, leave it at work.
Build judgment that travels.
Frame the decision. Defend the trade-off.
Carry the learning into the next system.