System Design Studio

Build the reasoning.

Start with a small system. Make the assumptions visible. Explain why it works.

Where are you starting?

Choose the guidance you want. You can change it without changing your draft.

I'm new to system designLearn the parts, one step at a time.I know the basicsRefresh the concepts and explore the exercise.I want interview practiceWork through the full exercise with optional help.

Select a starting point to begin.

First exercise

Design a URL shortener

Someone creates a short link. Another person follows it to the original page. Design the service that connects those two actions.

Decide what matters

Prioritize the behavior before choosing technologies. Keep analytics and custom aliases out of your first version unless they change a requirement.

Start from scratch: what is a system?

A system is a set of parts working together. Here, a client sends a request, an application handles it, and a store remembers the link. A requirement describes the result those parts must produce.

Functional requirements describe actions. Non-functional requirements describe qualities, such as response time or surviving a server failure. Give each target a reason.

Prioritized requirementsConstraints and exclusions

Describe the contract and flow

Write what a caller sends, what it receives, and what the service must remember. Trace creation and redirection separately.

What are an API, a data model and a data flow?

An API is the boundary a caller uses: a request and its response. A data model names the records you keep. A data flow follows one request through the parts of the system.

A short code can be a lookup key for its original URL. The store needs to reject a duplicate code rather than overwrite another link. Decide how to generate a new code and handle collisions.

API and stored recordCreation and redirect flow

Choose a baseline

Begin with a design you can explain end to end. Add a cache when reducing repeated lookups addresses a constraint you have named.

Architecture to exploreApplication + relational storeOne persistent code-to-URL mapping. Redirects read the store.Add a shared lookup cacheCache hits skip a store lookup. Misses still read the store.

Every redirect reads the store. Creates always persist a new mapping.

Open the editable Meeting Canvas →

What does caching change?

A cache keeps a reusable copy of a lookup result. A hit finds that copy; a miss falls back to the store. A cache can reduce store reads, but adds another component and a decision about how long copied mappings remain valid. Writes still need durable storage.

If links can change or expire, explain invalidation or expiry. If a cache fails, explain whether the store can handle the returning read load. A cache does not by itself prove lower response time or higher availability.

Stress your assumptions

Change the traffic mix and notice which part does more work. These are illustrative assumptions and arithmetic, not measured service capacity.

Total requests per dayReads / redirects 90%Cache hit fraction 80%Choose a cached baseline to apply this assumption.Peak multiplierLogical bytes per stored mappingRetention in days

Average requests / second: —
Peak requests / second: —
Peak store redirect lookups / second: —
Peak store creates / second: —
Logical mapping storage (decimal GB): —

Show the arithmetic and limits

Average request/s = daily requests ÷ 86,400.
Peak request/s = average request/s × peak multiplier.
Store redirect lookups/s = peak request/s × read fraction × (1 − effective cache hit fraction).
Store creates/s = peak request/s × (1 − read fraction).
Logical storage = daily requests × (1 − read fraction) × retention days × bytes per mapping.

The simple baseline uses a zero effective cache-hit fraction. Both actions share the assumed peak multiplier. One create makes one retained mapping; repeated writes, deletions, indices, replicas, cache memory, replication traffic and other requests are excluded. Decimal GB = bytes ÷ 1,000,000,000. These calculations cannot determine server count, latency, cost or production limits.

Defend one decision

Your tradeoff

Questions to challenge your draft

What happens if two creates propose the same code?
Could an expired or edited link remain in cache?
Where is the durable copy if an application instance disappears?
Would more reads or more writes change your next improvement?

Reflection and next practice

Review your reasoning

Prompts change when you write notes. They check field coverage, not correctness or interview readiness.

Keep your attempt

Attempt name

Saved attempts

Your draft stays on this page until you save or export it.

Saves are local to this browser. There is no account, upload or automatic assessment. Export a copy before changing browsers.

Learn a little. Apply it here.

Original exercise and illustrative calculations. These public resources offer deeper explanations and contrasting designs.

Hello Interview — introductionUnderstand what design interviews ask you to demonstrate.
Hello Interview — delivery frameworkConnect requirements, interfaces and architecture.
Hello Interview — core conceptsBuild vocabulary for the parts you are choosing.
System Design PrimerCompare approaches and explore tradeoffs.
AWS Well-Architected FrameworkAsk questions about operating the design, beyond the interview.

Focused foundation lessons with additional exercises
Failure scenarios and deeper scaling decisions
Timed cases and a richer self-review workspace