04QuestionsURL shortener

04 · Worked prompt

URL shortener

Design unique keys, redirects, abuse controls, analytics, cache strategy, and expiration.

25 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design unique keys, redirects, abuse controls, analytics, cache strategy, and expiration.

URL shortener system architecture. The key-to-destination mapping is truth; edge caches accelerate redirects but revocation stays version-aware. Request path: Creators + browsers to Global edge to Link service to Link mapping store. Asynchronous path: Link change stream to Analytics + abuse workers. Read path: Redirect service to Edge redirect cache. External dependency: Safe-browsing service. — URL shortener · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

The key-to-destination mapping is truth; edge caches accelerate redirects but revocation stays version-aware.

INTERVIEW CONTRACT

Design unique keys, redirects, abuse controls, analytics, cache strategy, and expiration.

CAPACITY QUESTIONS TO QUANTIFY

Read-dominant · global low-latency · billions keys · extreme hot skew. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Creators + browsers → Global edge
Create link / redirect enters over HTTPS / RPC. Global edge handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Global edge → Link service → Link mapping store
Link service receives the command, checks invariants and retry identity, then uses conditional put to update Link mapping store. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Link service → Link change stream → Analytics + abuse workers → Edge redirect cache
Link service emits publish after commit; Analytics + abuse workers uses consume and project / update to build Edge redirect cache. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Global edge → Redirect service → Edge redirect cache / Link mapping store
Redirect service uses cache lookup for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Link service → Safe-browsing service
dependency call crosses into Safe-browsing service. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Global edgeTLS, abuse, key routing	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Link serviceNormalize + allocate key	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Link mapping storeDestination, version, expiry	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Link change streamCreate/revoke/expire	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Analytics + abuse workersAggregate clicks + rescore	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Edge redirect cacheHot mapping + version	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Redirect serviceResolve + enforce policy	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Safe-browsing serviceDestination reputation	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: DynamoDB/Cassandra or a sharded KV store maps code→URL; SQL stores accounts; Redis/edge caches redirects; events feed analytics.
Partitioning / sharding: Hash short_code for even ownership. Allocate ID ranges/Snowflake IDs for unique codes; custom aliases use conditional claims.
Indexes: Primary short_code, owner listing (owner_id, created_at), unique alias, and expiry cleanup.
Replication + consistency: Create/delete/alias changes are strong conditional writes. Redirect reads may use eventual replicas and versioned caches.
Cache, queue + recovery: Cache redirects and misses with TTL/version; stream click events asynchronously so analytics never delays redirect.
Capacity math: Estimate redirects/sec, creates/sec, bytes/mapping × retention, hit ratio, hottest-link QPS, and event bandwidth.
Alternative rejected: SQL is enough initially; random key reads and independent analytics map cleanly to replicated KV at large scale.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Key generation

Use random base62 keys with collision check or allocated IDs with obfuscation

Random independence is often simpler than a central generator

Revocation

Version cache entries and push urgent purge for abuse or owner delete

A long TTL cannot become a safety loophole

Hot links

Cache immutable mapping at edge and protect the origin with request coalescing

The hottest key should be the cheapest request

Failure pressure test

Show detection, containment, recovery, and evidence.

Mapping store down

Serve safe cached mappings and fail closed on unknown keys

stale serves and unknown failures

Key collision

Retry generation before commit under unique constraint

collision count

Analytics lag

Drop or sample only by explicit product policy, never block redirect

event lag and loss estimate

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize create short links with optional expiry and redirect globally at low latency.”
Scale
“The design changes around read-dominant · global low-latency · billions keys · extreme hot skew.”
Decision
“Random keys avoid coordination; allocated sortable IDs ease uniqueness but reveal volume.”
Risk
“The first failure I want to pressure-test is: Hot links, malicious destinations, and stale edge caches create security risk.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Create short links with optional expiry
Redirect globally at low latency
Prevent collisions and malicious targets
Collect analytics without slowing redirects

URL shortener · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

active

expired

revoked

blocked

02Data model and APIs4 entities · 3 interfaces

Core entities

ShortLinkkey, owner_id, destination, created_at, expires_at, stateOwner: Mapping store

CreateRequestidempotency_key, owner_id, request_hashOwner: API service

ClickEventevent_id, key, region, occurred_atOwner: Event stream

AbuseDecisionkey, verdict, versionOwner: Trust service

External interfaces

POST /v1/links

Create or return a link under idempotency key

GET /{key}

Return redirect or terminal policy response

DELETE /v1/links/{key}

Revoke ownership and emit urgent cache purge

03Deep dives and trade-offsChoose one

Key generation

Use random base62 keys with collision check or allocated IDs with obfuscation

Random independence is often simpler than a central generator

Revocation

Version cache entries and push urgent purge for abuse or owner delete

A long TTL cannot become a safety loophole

Hot links

Cache immutable mapping at edge and protect the origin with request coalescing

The hottest key should be the cheapest request

04Failures, recovery, and evidence3 scenarios

Mapping store down

Serve safe cached mappings and fail closed on unknown keys

stale serves and unknown failures

Key collision

Retry generation before commit under unique constraint

collision count

Analytics lag

Drop or sample only by explicit product policy, never block redirect

event lag and loss estimate

05What makes the answer seniorInterviewer signals

Keep redirect latency independent from analytics
Expiry and abuse revocation are different policies
Clarify whether keys must be guess-resistant before choosing the generator
Primary trade-off: Random keys avoid coordination; allocated sortable IDs ease uniqueness but reveal volume.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Key generation

Revocation

Hot links

Show detection, containment, recovery, and evidence.

Mapping store down

Key collision

Analytics lag

Reference details

Core entities

External interfaces

Key generation

Revocation

Hot links

Mapping store down

Key collision

Analytics lag

Can you redraw it from memory?