匠人学院 JR Academy
Full exampleSystem Design

URL Shortener

Architecture decision record

Fictional person and company · Pre-generated example · No live AI call

Architecture

5 components
commitlookupon missClientCreate APIRedirectCacheMapping store
✓ Architecture✓ Decisions✓ Review
Question and example contextAlex Chen · Mid Backend Engineer

Harbour Link (fictional)

Design a URL shortening service. Explain the source of truth, redirect path, collision handling and degraded behaviour.

Decisions and review

6 sections
01

Requirements and assumptions

This fictional workload creates 100 million links per month, with 100 redirects per created link. Assuming a 30-day month, this is approximately 38.6 writes/s and 3,858 reads/s on average. These assumptions match the existing Lab topic; they are not measured peak capacity. Peak traffic, retention, regional availability and abuse policy remain open requirements.

02

Architecture and state ownership

A creation API validates the destination, allocates a code and commits the code-to-URL mapping to durable storage before acknowledging success. A redirect service checks the cache, reads the mapping store on a miss and then populates the cache. The mapping store is authoritative; the cache is a disposable copy. The diagram separates creation and redirect paths, even if a small initial deployment shares compute.

03

Collision and security decisions

A unique constraint detects duplicate codes; allocation retries after a conflict. Creation is rate limited and destinations are checked against an abuse policy. Random codes are not an access control mechanism. Private links would require an explicit authorization design.

04

Failure and recovery

When the cache fails, redirects may fall back to the store within a bounded concurrency budget; excess traffic receives a clear retryable failure. When both the cache misses and the authoritative store is unavailable, the service fails rather than inventing a destination. Recovery should warm popular keys gradually and monitor store saturation.

05

Trade-off and limits

The initial proposal uses a durable mapping store plus cache because reads dominate this assumed workload. This does not establish that one database meets production requirements. Sharding or regional replicas require evidence about peak load, storage growth, latency and consistency. No production load or recovery experiment was executed for this example.

06

Feedback and next action

The answer identifies the state owner and explains cache failure without treating cache as the only copy. It still needs a justified origin concurrency limit, peak-load assumptions, expiration semantics and a recovery experiment. Use the existing Lab to inspect the available topology and failure paths, then explain what changes under a new constraint. This feedback is pre-generated, not an employer assessment or a live AI result.

Next, explore your decisions

Explore data paths, architecture choices and failure behaviour in the interactive Lab.

Explore the existing Lab

Keep preparing

Mock interview
Companies, roles and common questions

你可能还想问

面试准备中最常见的困惑,我们帮你解答