Aviral Garg

System Design Studio

Explain your design.

Build a design you can explain, from requirements to tradeoffs.

Where are you starting?

Choose your guidance. Switching preserves your draft.

Choose your starting level

Select a starting point to begin.

Guided learning

Persist before replying.

A new short link needs a stored code-to-URL mapping. Choose where the application can truthfully report that the link was created.

A successful create request

  1. Browser1. Send the original URLCreate a short link for this URL.
  2. Application2. Prepare the mappingValidate the URL and choose a code.
  3. Persistent store3. Commit the mappingConfirm that the stored row is durable.
4. Reply to the browser: created. The application sends this reply after the store confirms the commit.

Request and stored record

Original URL
https://example.com/guide
Committed mapping
k7Q2 → https://example.com/guide

Reply after the commit

{
  "code": "k7Q2",
  "shortUrl": "https://short.example/k7Q2"
}

Illustrative design: a successful store acknowledgment means a durable commit. If the store explicitly rejects the write before a commit, the application reports creation failed and does not return a created-link reply. An uncertain write outcome needs separate reconciliation.

Why wait for the durable commit before replying? What should the application report when the store rejects the write?

Self-review your explanation against the three points below. Your words stay on this page.

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.

01

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.

02

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.

03

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 explore
ClientApplicationStorerequest / responsepersistent mapping
Every redirect reads the store. Creates always persist a new mapping.

Open Meeting Canvas →

Exports the illustrated baseline with all six notes and assumptions. In Meeting Canvas, choose Files → Import JSON. Review private details before sharing the file.

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.

04

Stress your assumptions

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

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.

05

Defend one decision

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?

Review your reasoning

Use these prompts to review your draft. They check which fields you filled, not whether your design is correct.

    Keep your attempt

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

    Saved attempts stay in this browser. Export a copy before changing browsers.

    Learning resources

    Further explanations and contrasting designs.

    Practice exercises

    Next
    • Additional timed cases