URL Shortener Follow-Ups: Failures, API Detail and Cost (2026)

The core design is done and the diagram looks right. Then the interviewer asks what happens when the cache restarts at peak, how a retried POST avoids making two links, and what the design costs per month. None of this changes the boxes. All of it decides whether the design survives a bad Tuesday.

This is the second half of Design a URL shortener, which builds the design itself. It holds the questions that fill the last fifteen minutes of the round.

Ask Before You Draw#

Spend the first two minutes on questions. Where the interviewer shrugs, state an assumption out loud and move on.

These are judgement calls, not facts. The point is that each one changes a later decision: accounts enable rate limits per user, and “no editing” is what makes 302 caching safe.

API Detail That Interviewers Probe#

The core lesson had two endpoints. A production contract needs more.

POST /links is not idempotentIdempotent: repeating the same request has the same effect as sending it once by definition: RFC 9110 section 9.2.2 lists only safe methods, PUT and DELETE as idempotent. A request that times out and is sent again can create two links. Two fixes:

• Idempotency key. The client sends an Idempotency-Key header, and the server stores the first response under (owner_id, key). Stripe may prune keys once they are 24 hours old and compares the parameters of a retry with the original. The header is still an Internet-Draft, not an RFC.
• Deterministic alias. Derive the code from the owner and the normalised long URL, so the same request always lands on the same row.

For GET /links?limit=20&cursor=..., use a cursor over (owner_id, created_at, code), not an offset. Assume 20 links a page: page 500 makes an offset query skip 10,000 rows. A cursor seeks straight to the next row. Limit creates with a rate limiter.

Data Model and Indexes#

Assume a 500-byte row, as in the core lesson.

links(code PK, long_url, host,
      owner_id, created_at,
      expires_at, status)
idx_owner(owner_id,
  created_at DESC, code)
idx_host(host)    -- takedown
idx_expiry(expires_at)
idem(owner_id, key PK,
  response, created_at)

• code serves the redirect. idx_owner serves the listing cursor.
• host disables every link to one bad domain in one statement.
• idx_expiry lets cleanup skip a table scan.

Do not index long_url: nothing queries by it, and each index adds write cost.

What Breaks, By How Much#

Every number here is an assumption carried over from the core lesson: 120 writes a second and 12,000 reads a second at peak, a 90 percent cache hit rate, and replicasReplica: a read-only copy of the database on another server that serve about 2,000 reads a second each.

Cache down is the stampede#

Assume one hot code gets 2,000 reads a second and a database fetch takes 5 ms. That puts 2,000 x 0.005 ≈ 10 fetches in flight for that one key. With request coalescingRequest coalescing: concurrent misses for the same key wait for one database fetch instead of each making their own it is one. Also keep a short local cache in each server and cap concurrent database reads, so overload becomes a few slow answers instead of an outage.

Counter down is a sizing question#

Assume 4 instances share 120 writes a second, so 30 each.

• Assume a block of 1,000: it lasts ≈ 33 seconds at peak.
• Assume a block of 10,000: it lasts ≈ 333 seconds, or 5.5 minutes.
• Assume a crash wastes at most one block: 10,000 of 3.52 trillion codes.

Alert when an instance holds under half a block.

Primary down can lose links#

It loses data if replication is asynchronous. Sentinel’s documentation says acknowledged writes are not guaranteed to survive a failover. For links, that means a user holds a code that later returns 404. Because writes are only 120 a second, a semi-synchronousSemi-synchronous replication: the primary waits for at least one replica to confirm a write before acknowledging it write path is affordable. State the RPORPO, recovery point objective: how much recent data you accept losing (about zero for links) and RTORTO, recovery time objective: how long recovery may take (about 30 seconds, an assumption) you chose.

Consistency: Two Answers, Not One#

The honest stance is split by operation. In CAP terms:

In PACELC terms, with no partition, reads trade consistency for latency (replicas and caches), while alias creation pays latency for consistency. This is design judgement, so say it as a choice you made, not a law.

Watch the Right Numbers#

Pick a few signals and give each a threshold.

• p99p99: the time 99 of every 100 requests beat; the slowest 1 percent are slower redirect latency at the read service, against the 100 ms target assumed in the core lesson.
• Cache hit rate. The database load is (1 - hit rate) x reads. Assume 90 percent: it is 1,200 a second. At 80 percent it doubles to ≈ 2,400. Alert at 85 percent (an assumption), where the load is 1,800, well inside the 6,000 limit.
• Assumed redirect availability SLOSLO, service level objective: a target for how well the service should perform of 99.9 percent. Assume 4,000 reads a second over 2.5 million seconds: ≈ 10 billion redirects a month, so the budget is 10 million failures, or 43.2 minutes of full outage in a 30-day month.
• Replication lag, blocks left per instance, abuse reports waiting.

Page on budget burn, not on single errors. The Google SRE Workbook recommends pairing a long and a short window: for a 99.9 percent SLO, a burn rate of 14.4 over one hour (confirmed over five minutes) pages, because it consumes 2 percent of the budget. Treat its numbers as a starting point to tune.

What It Costs#

Prices change, so these are dated and the rest are labelled assumptions. Assume the ≈ 10 billion redirects a month from above.

The lesson is the shape, not the totals. Edge serving bills every redirect, so use it for the hot codes and let origin caches take the rest. Cloudflare’s page also bills CPU time separately, so read it before quoting a total.

Deep Dive: Counting Clicks at Scale#

Assume 4,000 clicks a second and 50 bytes per event: 200 KB a second, about 17 GB a day. Writing a database row per click would put a write on the hot path.

• Emit and move on. If the log is slow, drop the event. A redirect never waits for analytics.
• Aggregate before writing. Assume a link with 2,000 clicks a second: it becomes one write every 10 seconds per code.
• Expect duplicates. Logs deliver at least once, so dedupe on an event ID where counts feed billing. Charts can tolerate small error.

See event-driven architecture and Kafka vs RabbitMQ for the log choice.

Deep Dive: Abuse and Takedown at Scale#

At creation, check the destination against a reputation service such as Google Web Risk, which says its lists can miss risky sites and flag safe ones. So add layers:

1. Rate limit and quota per user and per address.
2. Re-scan popular links on a schedule, hottest first, because a page can turn bad later.
3. Take down by host. idx_host disables every link to one domain in one statement.
4. Purge every layer: mark the row disabled, delete the cache entry, purge the edge.

The worst-case exposure after a takedown is the cache TTL or the edge max-age, whichever is shorter. Assume 60 seconds for both and say so. A 301 would make this unbounded, which is why the core lesson chose 302.

Rotating the Scramble Key#

The key is a secret, so sooner or later someone asks how to change it. Existing links survive, because a redirect looks up the stored code and never reverses the scramble.

The one place that does reverse it is the cross-region trick from the core lesson, which decodes a code to a number to find its home region. That is what depends on the key.

Rotation protects codes made after the change. It cannot un-leak codes already issued under a leaked key. Moving from 6 to 7 characters works the same way: codes are strings, so old ones stay valid.

Practice: Size the Block#

rate     = 120 / 4 = 30 per second
10 min   = 600 s
block    >= 30 x 600 = 18,000
choose   = 20,000 (a round number)
wasted   <= 4 x 20,000 = 80,000
share    = 80,000 / 3.52e12 ~ 2e-8

The 45-Minute Plan#

This is a suggestion. Cut cost before cutting the failure table.

What Each Level Should Show#

Check Yourself#

In One Picture#

Ask first
  accounts? aliases? regions?
API
  idempotency key, 409, 429,
  cursor paging
Failures
  cache x2 over capacity;
  block size = runway; RPO/RTO
Consistency
  reads available,
  alias consistent
Watch
  p99, hit rate, SLO burn
Cost
  edge bills every request
Rotate
  version the number ranges

Conclusion#

The follow-up answer is everything around the read-path machine: a create that is safe to retry, a failure table with numbers, a split consistency stance, budget-based alerts, an honest cost line and a way to change the key. State the assumption each time and the answers stay short.

Which follow-up would catch you out? Tell us in the comments.