System design starts with an observable user need and a few constraints. Estimate the load, draw the path a request takes, and choose where to store, cache, or queue work. A good design also explains what happens when a dependency is slow or unavailable.
Translate a product request into capacity and latency requirements.
Choose between a direct request and queued background work.
Explain cache freshness and invalidation.
Describe a graceful failure mode.
[ READ · TRY · CHECK ]
Your lessons are ready.
Everything below is available without an account. Pause at each question and make a prediction before opening the answer.
01
LESSON 01 / 03
Start with constraints
Estimate requests, data size, and the response time users can tolerate.
The idea
Start a design with constraints that a user could notice.
Write down who uses the system, peak request rate, data freshness, and acceptable response time. A news briefing can tolerate a short cache delay, while a submitted answer needs immediate confirmation. Estimate before choosing infrastructure.
A rough estimate is better than pretending capacity is unlimited. If 10,000 readers arrive in ten minutes, that is about 17 requests per second on average; a burst could be higher.
WORKED EXAMPLE
Estimate a briefing launch
10,000 requests ÷ 600 seconds ≈ 17 requests per second, before bursts or extra asset requests.
YOUR TURN
Which requirement matters more for a daily briefing: millisecond freshness or a clear “updated at” time?
Need a hint?
Think about what the product promises readers.
Check your answer
Usually a clear, reliable freshness timestamp. The exact target should follow the product promise and source update rate.
Try it further: Which part of a school news feed needs the freshest information?
02
LESSON 02 / 03
Store, cache, or queue
Place work according to how often it changes and whether a person must wait for it.
The idea
Move slow, repeatable work away from a reader’s request.
If a story summary takes several seconds to produce, compute it in a background job and save a reviewed result. Page requests can read the stored brief quickly. A cache helps with frequently read data; a queue helps with work that can finish later.
Caching creates a freshness question. Choose an expiry or invalidation rule and display the update time when stale content could mislead readers.
WORKED EXAMPLE
Separate two paths
Ingest → summarise → review → store is the write path. Browser → cache or database → page is the read path.
YOUR TURN
Should each page view run a new long summarisation?
Need a hint?
Would thousands of readers need identical work?
Check your answer
Usually no. Create and store the result once, then serve it until a new source or review changes it.
Try it further: Should a long news summarisation run inside a page request?
03
LESSON 03 / 03
Design for failure
Use timeouts, retries, and a useful degraded experience without hiding stale data.
The idea
Failure behaviour belongs in the design, not after it.
Set timeouts for external services and limit retries so one slow dependency does not consume all capacity. Keep a last-known-good snapshot if an upstream feed fails. Mark it with its real update time.
A graceful fallback preserves useful information without pretending that stale data is live. Test a timeout, an empty result, and a partial result before launch.
WORKED EXAMPLE
Handle a feed outage
Show the last reviewed briefing with “Updated yesterday”; disable claims that a new scan just completed.
YOUR TURN
Why can unlimited retries make an outage worse?
Need a hint?
Consider how much work retries add to an already struggling service.
Check your answer
Retries amplify load and can exhaust connections or queue space. Use bounded retries and a fallback.
Try it further: What should users see if the source service is unavailable?
[ PUT IT TO WORK ]
Diagram a daily briefing service
Draw ingestion, review, storage, and read paths for an AI news briefing. State a freshness target and what the page shows during an outage.
Check your work
The read path avoids unnecessary expensive work.
Freshness is shown to the reader.
One dependency failure has a clear fallback.
[ GO DEEPER / FOLLOW THE SOURCE ]
Further reading
These sources support further study. The lessons above are original AI Ka School material.