Explain a system-design diagram, one request at a time.

01 / Draw only what you can explain

One short link. Two places to look it up.

Our fictional service maps a short code such as /r7k to a destination URL. Focus on the read path in one region. Link creation, abuse review and multi-region replication are separate design topics. Links have an expiry time; the redirect service checks it before returning a destination.

Handcrafted illustrative architecture. This is a teaching sketch, not a ClawPad screenshot or generated answer. The values below are assumptions, not measured results.

Read the picture aloud. The browser asks the redirect service for a code. The service checks a temporary cached mapping first and queries the authoritative link store only when needed. It validates the result and returns either a redirect or an explicit error. Each box is a logical responsibility, not a claim that one machine is enough.

02 / Follow the arrows

Tell four stories about the same diagram.

1. A / Cache hit

   The destination is already cached.

   The browser requests /r7k. The service reads its cached mapping, checks that the link has not expired and returns HTTP 302 with the destination in the Location header. The browser then requests that destination. The link store receives no read on this path.

   Say what comes back, not only which box gets called.

2. B / Cache miss

   The mapping exists only in the link store.

   A miss is not evidence that the link is missing. Read the store by code. If a valid mapping exists, attempt to cache it and return the redirect. Choose a cache time to live (TTL) of at most 60 seconds, shortened to the link’s remaining lifetime. A cache write failure need not discard a successful store read.

   Return “not found” only after a successful lookup finds no mapping. An expired mapping gets an explicit expired-link response.

3. C / Cache unavailable

   Fallback needs a limit.

   After a bounded cache timeout, use the link store only within a capped fallback budget. Limit concurrent store reads and reject excess work with a temporary service error. Otherwise, a cache outage turns every redirect into a database read and can take down the remaining healthy dependency.

   Explain the timeout, admission limit and error response. “We fall back” leaves the overload behavior undefined.

4. D / Store unavailable

   Unknown is different from missing.

   A still-valid cache hit can serve a redirect under this example’s freshness policy. A miss that reaches an unavailable store returns a temporary service error, such as HTTP 503. Do not turn the timeout into a 404 or cache it as a nonexistent code. Record cache timeouts, store failures and rejected fallback requests separately.

   If the requirements demand an authoritative check on every request, cached availability no longer buys you this behavior.

Protocol reference: HTTP 302 and the Location header in RFC 9110. This example’s 60-second TTL and fallback policy are teaching choices.

03 / Put a cost next to the choice

A cache saves reads. It also creates a freshness problem.

Also specify browser and intermediary caching. For this exercise, return Cache-Control: no-store on redirects so future navigations reach the service. A 302 status alone does not define the whole caching policy. Already issued redirects cannot be recalled.

Further reading: Microsoft’s cache-aside pattern and consistency limits and the HTTP no-store response directive.

04 / Continue when the requirements change

“Make it 10 million redirects a day. Revoked links must stop.”

Original illustrative continuation by the ClawPad editorial team. Reviewed October 13, 2026. These are assumed traffic and policy choices, not measured capacity or a generated model result.

Keep one region and the same destination cache. Increase demand to 10 million redirect requests/day and assume a peak of 12 times the daily average. Keep a 95% destination-cache hit rate at that peak. For the calculation, assume all requests refer to valid, active links, one lookup per step, no retries and no request combining.

Define “stop” before drawing. After a revocation write is acknowledged, every authorization check that starts later must reject that code. Checks already in flight may race with the write; redirects already issued cannot be recalled. If the requirement instead forbids every redirect response after acknowledgment, this design needs additional coordination of in-flight requests.

1. Active + hit

   The cache no longer avoids every dependency.

   Check the authoritative active/revoked state by code using a strongly consistent read. If active, read the destination cache, validate expiry and return 302 with Cache-Control: no-store. Do not cache the active decision. Unknown codes or missing authority records are denied, never assumed active.

2. Active + miss

   Keep the existing bounded fallback.

   After the authority allows the request, read the mapping store within the fallback budget. Validate expiry, optionally fill the destination cache, and return the redirect. A mapping-store timeout returns 503; it does not mean the link is absent.

3. Revoked / failure

   Fail closed when the new dependency is unavailable.

   A known revoked link returns an explicit disabled-link response, such as 410. A timeout or unavailable authority returns 503 even with a cached destination. With a healthy authority but an unavailable mapping store, a valid cached destination can still be served. With no usable cache, admit only bounded mapping-store traffic and reject excess work.

The revocation writer acknowledges only after the authority has committed the change. Link creation must make its mapping available before making the code active. A stale replica, cached allow decision or asynchronous revocation feed cannot satisfy the chosen check-after-acknowledgment rule.

Recalculate each dependency in requests per second

The authority workload remains when the cache fails. Mapping-read demand rises 20 times under these assumptions. These numbers exclude writes, replication, cache fills, denied requests, retries and operational headroom. Measure sustainable throughput and latency before choosing admission limits, concurrency or a database size.

const secondsPerDay = 86_400;
const dailyRedirects = 10_000_000;
const peakMultiplier = 12;
const hitRate = 0.95;
const averageRps = dailyRedirects / secondsPerDay;
const peakRps = averageRps * peakMultiplier;
const mappingReadsAtPeak = peakRps * (1 - hitRate);
const authorityChecksAtPeak = peakRps;
const wrongAverageRps = 1_157.41; // Deliberate 10x error.
const rows = [
  ["Average redirects/s", averageRps, 115.74],
  ["Peak redirects/s", peakRps, 1388.89],
  ["Peak mapping reads/s, cache healthy", mappingReadsAtPeak, 69.44],
  ["Peak authority checks/s", authorityChecksAtPeak, 1388.89],
  ["Peak mapping reads/s, cache unavailable", peakRps, 1388.89],
];
for (const [label, actual, expected] of rows) {
  if (Number(actual.toFixed(2)) !== expected) throw new Error(label);
}
if (Math.abs(wrongAverageRps - averageRps) < 0.01) {
  throw new Error("The deliberate arithmetic error was accepted");
}
console.table(rows.map(([quantity, value]) => ({
  quantity, value: value.toFixed(2)
})));
console.log("Wrong average: 1157.41; corrected: " + averageRps.toFixed(2));
console.log("Whole-request peak rounded up: " + Math.ceil(peakRps));

What does ClawPad’s on-device capacity check establish?

The structured system-design validator checks specific supplied fields. Peak requests per second must match daily requests multiplied by the peak factor, divided by 86,400, then rounded up. Peak bytes per second must equal that whole-request rate multiplied by the supplied average payload bytes.

That consistency check does not measure traffic, prove that payload assumptions are realistic, check every calculation in prose, or certify the architecture. It is not a general consulting or finance calculator. Managed AI answer generation still uses cloud services; a local arithmetic check does not mean screenshots, audio or submitted profile context stay on device.

From the notebook to the desktop

Use ClawPad’s diagrams as material to question.

ClawPad can present structured architecture diagrams and database views alongside staged system-design guidance. Diagram views support pan and zoom. Available content depends on the answer, and generated designs can contain mistakes. Check the request paths, assumptions and failure behavior yourself.

Try a practice prompt, explain the diagram without reading the answer, then change one constraint. ClawPad presents written guidance; it does not speak the answer for you. Where audio is supported and ready, explicitly started Live Assist can process spoken questions. Get permission before processing anyone else’s speech. The exercise above works on paper too. Use only where assistance is explicitly permitted.

Questions about system-design diagrams