Url Shortener on Tech Foundations

Url Shortener

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener”

linkTitle: “URL Shortener”

Core Requirements

Functional Requirements

Users should be able to access the original URL by using the shortened URL.
Users should be able to submit a long URL and receive a shortened version.
- Optionally, users should be able to specify a custom alias for their shortened URL.
- Optionally, users should be able to specify an expiration date for their shortened URL.

Below the line (out of scope):

Url Shortener Additional

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener Additional”

linkTitle: “URL Shortener Additional”

Back-of-envelope (40-50s)

Keyspace: need ≥1B codes -> base62^5 ≈ 916M (<1B), base62^6 ≈ 56.8B -> choose 6-char minimum, expandable to 7-8.
Traffic: say 100M DAU, ~5 resolves/day ⇒ 500M/day ≈ 5.8k QPS avg; peak ×10 ≈ 58k QPS read. Writes are much smaller (≪1k QPS).
Storage: 1B rows × ~1 KB/row (URL, code, meta) ≈ ~1 TB raw (before replication).

(These numbers justify caches, partitioning, and avoiding hot databases on read path.)

Url Shortener Agentic

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener Agentic”

linkTitle: “URL Shortener Agentic”

1. Roo-Code local service

Prompt to Architect mode in roo-code: I need to build and MVP of url-shortener. It will have minimal functionality: just what need to be implemented to enable Redirect and Write Paths from @/docs/url-shortener.md . Api is specified in @/api/openapi.yaml . About structure: it will be one service with db. Later I’ll evolve it to microcervice architecture. Provide a plan to implement High-Level Design and write it to ‘docs/plan.md’ (for example)

Url Shortener Nfrs

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener NFRs”

linkTitle: “URL Shortener NFRs”

hellointerview variant

Core Requirements

The system should ensure uniqueness for the short codes (no two long URLs can map to the same short URL)
The redirection should occur with minimal delay (< 100ms)
The system should be reliable and available 99.99% of the time (availability > consistency)
The system should scale to support 1B shortened URLs and 100M DAU

Below the line (out of scope):

Url Shortener Nfrs V0

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener NFRs v0”

linkTitle: “URL Shortener NFRs v0”

Other to consider:

Document how deactivate/expire signals propagate to caches and storage to bound staleness and avoid serving dead links beyond the intended window
Adopt cache‑aside on the app with optional background warm on create, and define stale‑on‑error behavior for resilience during short origin disruptions
Specify edge and regional cache TTLs for hot keys, negative‑cache TTLs for 404/410, and cache‑bust rules on deactivate/expire to ensure user‑visible correctness with minimal origin hits
Observability: Emit edge and app metrics for success rate, latency (p95/p99), dependency health, and burn‑rate, add synthetic checks for top links, and define alert thresholds aligned to SLOs.
Provide concise runbooks for cache hot‑key misses, regional degradations, store throttling, and rollback procedures to accelerate MTTR within the error budget
Capture cutover mechanics such as DNS/health‑based routing, data replication mode, and rollback safety so the path to 99.99% is real but gated

API and contract polish

Url Shortener Useful

Mon, 01 Jan 0001 00:00:00 +0000

title: “URL Shortener Useful”

linkTitle: “URL Shortener Useful”

From a product marketing perspective, “Analytics” might be the core value proposition you sell. But from a system implementation and user-experience perspective, Redirection is the non-negotiable, foundational core of the entire product.