Defend a design. Show your work.
Turn the Relay project into evidence of engineering judgment for a team, a portfolio, or an interview.
BY THE END, YOU CAN
- Translate requirements into explicit design decisions
- Estimate capacity with stated assumptions
- Communicate tradeoffs, evidence, and unresolved risks
Diagram description: Constraints → Options; Options → ADR; ADR → Evidence; Evidence → Portfolio; ADR → Portfolio
Start with constraints, not products
A system-design discussion begins by clarifying users, operations, workload, latency, durability, security, and cost.
Ask which guarantees matter most and what can be relaxed. Estimate magnitudes with units and show your assumptions. If one million jobs arrive per day, the average arrival rate is roughly twelve per second, but peak rate and job duration determine worker needs.
An average alone is not a capacity plan. Begin with the simplest architecture that meets the requirements, then identify the next bottleneck or failure boundary.
Make a decision reviewable
A short architecture decision record states the context, alternatives, chosen approach, consequences, and conditions that would trigger reconsideration.
For Relay, compare a database-backed queue with a dedicated broker using durability, ordering, throughput, operational burden, and team familiarity. There is rarely one universally best answer. A strong engineer explains why a choice fits these constraints and what evidence could change it.
Include failure cases, migration paths, and cost of ownership rather than evaluating only throughput on a clean benchmark.
A portfolio is evidence of judgment
Present a runnable project, a concise architecture diagram, a clear setup guide, meaningful tests, and a small record of measured behavior.
Show one bug you diagnosed, one tradeoff you changed after evidence, and one limitation you chose deliberately. For interviews, narrate assumptions, test cases, and complexity while solving a problem; invite clarification instead of silently guessing. For a working team, connect technical work to user outcomes and operational consequences.
Completing this course is a starting point: mastery grows through review, real constraints, and repeated practice.
COMMON FAILURE MODE
A portfolio full of technology names but no reproducible behavior or explained decisions gives reviewers little evidence of engineering skill.
TRY IT YOURSELF
Prepare a five-minute Relay design review: requirements, architecture, one capacity estimate, one failure scenario, one tradeoff, and the next experiment you would run.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Publish a local Relay portfolio package: README, architecture decision, tests, benchmark notes, threat model, SLO, and incident exercise. Explain its limits honestly.