MODULE 02 / 18 · PART 1 · DECIDE & DESIGN
Architecture & System Design
Choose a design by its trade-offs, failure modes and operating cost — not by confidence.
THE SHORT ANSWER
What this module changes.
Architecture prompts work best when they demand options. Ask for components, data flow, failure modes, operating cost, and the condition under which each design is the wrong choice.
Architecture prompts work best when you demand options rather than an answer, and when you force the agent to name the trade-off it is making. Never accept a single design without its rejected alternatives.
Systems built for East African organisations rarely fail because the diagram was unfashionable. They fail because a mobile-money webhook arrived twice, a district office lost connectivity, or one person became the only operator who understood the reconciliation spreadsheet. Design for those conditions explicitly.
THE MODULE PROMPT LIBRARY
20 prompts for architecture & system design.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Give me 2–3 architecture options for [problem]. For each: components, data flow, failure modes, operational cost, and the condition under which it is the wrong choice.
Why it worksOptions with explicit disqualifiers beat a single confident recommendation.
Design [system] and then argue against your own design. What breaks first at 10x load?
Why it worksForces the agent to stress-test its own proposal instead of defending it.
What are the boundaries of this service? List what it owns, what it must never own, and where the seams are.
Why it worksClear ownership boundaries are what keep a service from becoming a distributed monolith.
Draw the sequence diagram for [flow] in text form, including the failure path at each step and what the caller sees.
Why it worksMakes the unhappy paths first-class citizens of the design.
Where should this logic live: [logic]? Give me the argument for each candidate layer and the coupling cost of each.
Why it worksTurns a placement argument into an explicit coupling trade-off.
Identify the single points of failure in this design: [design]. For each, what is the blast radius and the cheapest mitigation?
Why it worksFinds the components whose failure takes the whole system down.
What is the consistency model here, and what does the application have to do to tolerate it? Be specific about read-your-writes and ordering.
Why it worksConsistency assumptions are where distributed systems quietly break.
Propose the interface contract for [component]: methods, inputs, outputs, error semantics, idempotency, and versioning strategy.
Why it worksAn explicit contract is what lets two teams build in parallel without integration hell.
What would this architecture look like if we had to run it with a team of three? What would we cut?
Why it worksReveals the operational complexity that a large-team design hides.
Compare synchronous vs asynchronous handling for [flow]. Give me latency, failure semantics, complexity, and debuggability for each.
Why it worksMakes the sync/async decision on evidence rather than fashion.
Design the data model for [domain] and show me the access patterns it optimizes for and the ones it makes painful.
Why it worksData models are access-pattern decisions; naming the losers prevents surprises.
What are the extension points in this design? Where will the next three features attach, and does that require a change to the core?
Why it worksTests whether the design is actually open for extension or just claims to be.
Here is the current architecture: [context]. What is the smallest change that solves [problem] without a rewrite?
Why it worksGuards against the reflexive rewrite that senior engineers should resist.
Identify the coupling in this design: [design]. Which modules change together, and how do we break that dependency?
Why it worksChange-coupling is the real measure of a design's health.
What are the backpressure and overload strategies for [system]? What happens when the queue is full?
Why it worksOverload behavior is a design decision, not an accident to be discovered in an incident.
Propose the deployment topology for [system]: instances, regions, state, and what a rolling deploy does to in-flight requests.
Why it worksConnects the logical design to what actually happens during a release.
What is the migration path from the current design to this one, step by step, with the system shippable at every step?
Why it worksAn architecture you cannot migrate to incrementally is not a plan, it is a wish.
Review this design against the twelve-factor and cloud-native principles: [design]. Where does it violate them and does it matter here?
Why it worksApplies a known checklist without treating it as dogma.
What are the three hardest questions a skeptical staff engineer would ask about this design, and what are the honest answers?
Why it worksPre-runs the design review you are about to face.
Given these quality attributes [attributes], rank the architectural tactics by cost-effectiveness for this system.
Why it worksTies architecture decisions to the attributes the business actually cares about.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Pick one system you operate. Run prompt 3 (boundaries) and prompt 5 (single points of failure). Write a one-page decision record with the option you rejected and why.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.