Capstone Design a Short Link Service End to End

01 The idea

The problem this lesson solves

Write features, excluded analytics, mutable-destination policy and measurable targets.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

A complete design connects each guarantee to the request path and state transition that enforces it.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Exhaust the simpler explanations first

Inspect slow queries, missing indexes, connection-pool saturation, lock contention and unnecessary work before splitting data. A single well-sized relational database can serve many workloads. If reads dominate and can tolerate lag, replicas may help. If one node cannot hold or serve the write workload despite reasonable tuning, evaluate sharding against its operational cost. Base the decision on measured constraints and growth forecasts.

One primary partitioning choice cannot optimize every query

For a short-link service, sharding by short code makes redirect lookup a single-shard operation. An owner's ‘list all my links’ query then spans many code partitions unless you maintain a separate owner index or materialized view. Sharding by owner solves the listing but requires another route from code to owner for redirects. State which access path matters most and how the secondary path stays correct. A globally unique code also needs a deliberate generation or collision-check strategy.

Cross-shard queries and transactions are design costs

A global top-k query may ask each shard for its local top k and merge the candidates under the same total order. A scattered query's latency is affected by its slowest participant; partial failures need a policy. Global uniqueness, joins and all-or-nothing writes across shards may require extra coordination or a workflow with compensating actions. Do not pretend a transaction that is easy inside one SQL database remains equally simple after partitioning.

Connect the artifacts

Start with create and redirect in one region. Define whether links can change, who can manage them, how long they live and what success means. Use scoped idempotency for management creations and a unique code in durable storage. A public redirect begins with the code; an owner listing begins with owner identity.

Trace both operations through the same architecture. Management requests authenticate and authorize. A redirect may use an eligible cached mapping but must distinguish missing from unavailable. The cache key and freshness policy must match destination mutability. Each diagram arrow should name an operation and the relevant identity.

Let the capacity worksheet constrain complexity

Use the course’s declared workload first: 100,000 DAU, ten redirects each per day, ten thousand creations daily and a five-times peak factor. This gives approximately 57.87 peak read QPS and 0.579 peak creation QPS before additional work. One-year logical mapping data at 500 bytes each is 1.825 GB.

These numbers alone do not justify sharding. A relational source of truth with measured queries and a modest stateless app pool is a reasonable candidate to test. If growth later requires partitioning, explain code routing and the owner-listing secondary path. Keep the revisit threshold measurable instead of declaring the first design infinitely scalable.

Defend the five incidents

A lost create response needs replay of the original result. A stale fill needs the declared freshness contract or a stronger path. A cold cache needs bounded origin work. An app failure needs routing removal, safe retry and surviving capacity. Replica lag needs a client consistency policy.

For each incident, write what the user sees, who owns recovery and what signal reveals the problem. Avoid a diagram that silently assumes every dependency is redundant or every failure is retryable. The review is finished when another reader can execute both the happy path and the incident paths using only your packet.

Guided tutorial

1. Assemble the service

Draw client → DNS/entry → load balancer → stateless app → cache → database. Add create and redirect endpoints, owner authorization, code uniqueness and the conditional behavior of mutable destinations. Separate management APIs from public redirects.

2. Attach a capacity worksheet

Reuse the estimation module's declared workload. Estimate reads, writes, retained data, misses and capacity during one instance loss. Decide whether a single relational database is still enough before drawing shards.

3. Defend failure behavior

Explain a lost create response, stale cache fill, cold cache, app-server failure and replica lag. For each, state the user-visible result, a recovery mechanism and one metric that reveals the failure.

4. Deliver a reviewable packet

Produce one page of requirements, one diagram, an API table, a schema sketch, a capacity worksheet and a trade-off log. If you choose sharding, include the secondary owner-listing path and a migration plan; otherwise document the threshold that would make you reconsider.

requirements → API and authorization table
API → schema keys and atomic transitions
workload → QPS, storage and failure capacity
request flow → routing, cache and authoritative store
incident review → user result, recovery owner and metric
trade-off log → choice, cost, risk and revisit trigger

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions