High-Level Design Workshop

Retrieval Prompts

1. Name the five required annotations on any box diagram (hint: API surface, arrow types, stores, boundaries, box labels).
2. What goes on the left edge of the diagram, and why?
3. Name four storage families and one workload each is the best fit for.
4. State the four questions the storage-choice template answers, in order.
5. Name the five-line justification template for any cache/CDN/LB you add to the diagram.

Compare and Distinguish

Separate cleanly:

• wide-column store vs document store vs KV store
• cache-aside vs write-through vs write-back vs refresh-ahead
• L4 load balancer vs L7 load balancer
• CDN vs reverse proxy vs application cache
• polyglot persistence vs "one database for everything"

Produce a one-sentence distinction for each pair that a reviewer would accept.

Common Mistake Check

Identify the flaw:

1. "We will use MongoDB because it's flexible." (What is missing from this sentence?)
2. "Every service gets its own Redis cache." (When is this right; when is it wrong?)
3. "Our database is the primary; we'll add a cache later." (What premature optimization is baked in, and which genuine debt is not?)
4. "This endpoint has strict consistency, so we cache it." (What specifically is wrong?)
5. "We put a CDN in front of everything." (What danger is lurking here?)

Mini Application

Pick two prompts from your framing lab (practice 1). For each, produce in under 15 minutes:

1. A box-and-arrow diagram with 6-12 labeled boxes, API surface on the left edge, and arrow types marked.
2. A seven-line storage sketch per primary workload (at least 2 workloads per design).
3. A five-line justification for every cache, CDN, and load balancer on the diagram.

Pin each diagram for later use in the Stress Test Clinic (practice 3).

Cross-Design Comparison

After producing at least three diagrams across different problem types (read-heavy, write-heavy, real-time, strongly-consistent), build a small comparison table:

| Design | Primary store | Hot cache | Read vs write emphasis | Partitioning key | One hard part |

Use this to notice your own patterns. If every design ends up with the same storage shape, you are templating rather than designing.

Anti-Pattern Hunt

In one of your existing diagrams, identify and fix at least one of:

1. A secondary index you cannot name a query for.
2. A cache that serves data the application has not established can go stale.
3. A load balancer with sticky sessions but no clear reason for the stickiness.
4. A stateful service that has no failover story.
5. A shared Redis cluster serving unrelated teams/workloads (a blast-radius smell).

Evidence Check

This page is complete only if:

• you have two diagrams, each with 6-12 labeled boxes, API surface column, arrow-type marks, and region/trust-zone boundaries
• you have a seven-line storage sketch for every primary workload across the two designs
• you have a five-line cache/CDN/LB justification for every such component you drew
• you can point at any box and say what it owns and why it is there in under 15 seconds
• you have identified and fixed at least one anti-pattern in your own work