Technical craft

System Design

5 lessons · ~31 min total

Start with the requirements, not the boxes

~6 min

Pin down the functional and non-functional requirements before drawing a single component, so the design answers a real problem instead of an imagined one.

Key takeaways

Non-functional requirements (load, latency, consistency, durability) shape the architecture; functional requirements alone don't.
Attach a number to every requirement: 'p99 < 200ms', not 'fast'; '2k writes/sec', not 'scalable'.
Every component in a design should trace back to a stated requirement; an unjustified box is decoration.

There is no best design, only trade-offs

~6 min

Name the property you're buying and the one you're giving up on every significant decision, so choices are deliberate rather than inherited defaults.

Key takeaways

Every significant design choice buys one property at the cost of another; state both sides, not just the benefit.
Under a network partition you get availability or consistency, never both (CAP). Decide per access pattern.
'Best design' is meaningless without 'for what'; match each choice to the actual requirement in front of it.

Find the bottleneck before you scale

~6 min

Locate the single tightest constraint in a system and reason about it with rough numbers before adding any scaling machinery.

Key takeaways

A system is only as scalable as its tightest constraint, usually a stateful component; scaling anything else is motion, not progress.
Do the back-of-the-envelope estimate before designing for scale; order of magnitude decides whether the worry is real.
Adding stateless replicas doesn't help when the bottleneck is the database, a single writer, or the connection pool.

Design for failure, not just success

~6 min

Assume every dependency will fail and design the blast radius, degradation, and retry behavior on purpose rather than by accident.

Key takeaways

If you haven't decided how a system fails, you've decided by accident, and the accident is usually a cascade.
Bound every dependency with a timeout and a graceful fallback; a call with no timeout is a latent outage.
Any write that can be retried must be idempotent. The retry, not the outage, causes the duplicate-action incident.

Evolve the system without a rewrite

~7 min

Migrate a live system in reversible steps: seams, strangler moves, and parallel runs.

Key takeaways

Rewrites must reimplement years of folklore behavior before delivering value; stranglers ship value monthly.
Seam first, then one slice at a time, with rollback as a config change and the old path alive until the new one carried real load.
Ramp by exposure to the ugly traffic shapes, not by calendar time.

Try a sample check

A sample from the Strategy & Prioritization track. The real checks unlock with an account.

Strategy & Prioritization

Leadership asks you to commit your team to a deadline you are confident is two weeks short. The room is waiting. What do you say?

Start System Design.

Your first lesson takes five minutes, and you can do it right now without an account.

Try the first lesson Create your account