CHAPTER 03 / 13 · READ → DECIDE → BUILD

Choose a system you can explain.

Translate product rules into technical responsibilities.

18 min + practiceA TRD and decision recordJump to practice ↓

Follow one request

Draw a path from the browser to the server to the database. The browser shows a task and submits a claim request. The server identifies the user, validates the request, and checks the operation. The database enforces the rule that competing claims cannot both succeed. The server returns a stable result and the browser explains it. This simple diagram clarifies where trust changes and which component owns each responsibility.

Make trade-offs explicit

A small application with a relational database is a useful starting candidate for this example, not a universal rule. Compare it with alternatives using your team's skills, operating costs, expected usage, and recovery needs. Avoid splitting into services just because the agent suggests it. Record the reason for a decision and the evidence that would justify revisiting it. Unknown scale should be labeled as an assumption, not turned into an invented traffic forecast.

Choose tools without locking the lesson to a vendor

Ask your agent to inspect installed versions before writing framework-specific code. Keep secrets on the server and use a separate test database. Decide how authentication, hosting, and model usage will be paid for. A TRD should name required environment variables without their values. If a provider feature is essential, check its official documentation and current plan limits before making the architecture depend on it.

SEE THE DIFFERENCE

A small example. A better decision.

THE INITIAL APPROACH

The client sends volunteer_id and the server trusts it.

THE MORE USEFUL APPROACH

The server derives the volunteer's identity from its authenticated session. The client supplies the task ID, which the server validates before requesting the claim.

Client input can identify the target of an operation; it cannot establish who has permission to perform it.

Your build steps

Draw the request path for claiming a task.
Assign validation, identity, and invariant enforcement to specific components.
Compare two viable stacks using your constraints and current official documentation.
Write a short architecture decision record and save your TRD.

FROM THE PROMPT LIBRARY

A useful brief for this step.

Translate the PRD into a TRD ↗Connects product promises to concrete technical responsibilities.Choose the simplest viable architecture ↗Avoids unnecessary distributed-system complexity.Write an architecture decision record ↗Preserves why a technical choice was made.All architecture & trd prompts

MAKE THE CALL

Think like the reviewer.

Your tiny app has no measured scaling problem. The agent proposes five services. What should you ask?Which requirement needs that complexity, and could a simpler design satisfy it?Can we add another service for future-proofing?Can we skip the design and let the agent choose?

BUILD YOUR WORKBOOK

A TRD and decision record

0/3 notes ready

Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.

1. Request path and responsibilitiesAdd a specific note of at least 20 characters.2. Chosen stack and trade-offAdd a specific note of at least 20 characters.3. When would you revisit this decision?Add a specific note of at least 20 characters.

Before moving on

I can trace a request through the system.Identity and permissions are enforced outside browser code.I recorded one trade-off and a trigger for reconsidering it.

Loading your workbook…