URL Shortener — system design by FierceOtter34

NFRs are listed but not made measurable enough

The section mentions availability, latency, scalability, durability, fault tolerance, and uniqueness, which is a reasonable start, but most of them are not quantified. For a senior-level answer, availability should be expressed as an SLA/SLO (for example 99.9% or 99.99%), latency should specify percentile and scope (for example p95 or p99 for redirect vs create-short-URL APIs), and durability should be stated with a target. Add concrete targets so the design can be evaluated objectively.

Consistency model is not defined

The answer does not state whether the system requires strong or eventual consistency for URL creation, uniqueness enforcement, and reads after writes. This matters because uniqueness of short URLs usually needs strong guarantees at write time, while analytics or replicas may tolerate eventual consistency. Explicitly call out which operations require strong consistency and which can be eventually consistent.

Numbers are not tied to workload assumptions

The latency target is given, but there are no assumptions about traffic volume, read/write ratio, peak QPS, storage growth, or regional distribution. At senior level, NFRs should be justified against expected scale so it is clear whether the targets are realistic. Tie the <100 ms and <1 second goals to expected request rates and peak load assumptions.

Relationships between entities are not defined

The entities are listed, but the design does not state how they relate to each other. For a senior-level core-entities section, you should explicitly define relationships such as whether one User can own many URLMetaData records and whether each URLMetaData belongs to exactly one User or can exist anonymously.

Core flow entity coverage is too thin

For a URL shortening domain, User and URLMetaData cover part of the model, but the core flow is underspecified at the entity level. If the functional requirements include creating and resolving shortened URLs, the shortened URL itself should be represented clearly as a first-class domain concept rather than being implied inside URLMetaData. Add an explicit ShortURL/Link entity or clearly redefine URLMetaData as the canonical shortened-link entity.

Calculations stop at averages and ignore peak load

Using only monthly averages understates required capacity. Real systems need peak QPS assumptions (for example 2x-10x average, plus diurnal traffic skew) to size app servers, databases, caches, and network links. Add peak write/read QPS and design against those numbers, not just the average 40/400 QPS.

Capacity model is not methodical end-to-end

The section goes from monthly volume to average QPS and storage, but does not continue into bandwidth, cache hit assumptions, replication overhead, index/storage amplification, or growth over retention. For a senior-level answer, extend the chain from traffic to storage and network: request size x QPS, response size x QPS, DB replication factor, index overhead, and backup requirements.

No linkage from numbers to infrastructure sizing

The calculations are not tied back to whether the proposed high-level design can handle the load. Senior-level capacity work should explicitly map 400 read QPS / 40 write QPS (and peak values) to expected database capacity, cache need, shard count if any, and whether a single primary with replicas is sufficient.

URL design is not resource-oriented

The create endpoint uses an action-style path (/shorten) rather than a resource-oriented REST design. For a senior-level API, model shortened links as a resource, e.g. POST /urls or POST /links, and return the created short-link resource including its id/code and metadata.

CRUD coverage for the primary resource is incomplete

Only create and redirect are defined. If the shortened URL is the primary entity and expiration/custom alias are part of its lifecycle, the API should also define at least a retrieval endpoint for metadata (e.g. GET /urls/{code}) and, if supported by the requirements, update/delete semantics. Without this, the resource model is only partially exposed.

HTTP status codes for creation are not ideal

POST /shorten returns 200, but resource creation should typically return 201 Created, ideally with a Location header pointing to the created resource. This makes the API more standard and easier for clients to integrate with.

Redirect behavior is underspecified

The design says 301 or 302 but does not define when each is used. That ambiguity can cause inconsistent client and cache behavior. Specify a clear rule, such as 302/307 for normal redirects if destinations may change, or 301/308 only when permanence is guaranteed.

Error handling is too narrow

Only the 409 alias-conflict case is defined. A robust REST API should also specify common failure responses such as 400 for invalid URL or malformed request body, 404 when a short code does not exist, and 410 if an expired link is accessed. Define a consistent error response schema with code/message fields.

Cache ownership and access pattern are inconsistent

Both the read replicas and write service talk to Redis, but the responsibilities are unclear. The note says Redis is used to check custom alias uniqueness, while the read path also appears to depend on it. This creates confusion about whether Redis is a read-through cache, write-through cache, or just a temporary uniqueness check. Define a clear pattern: for example, lookup service checks Redis first for shortCode->originalUrl, falls back to DB on miss, and write service populates or invalidates cache after successful writes.

No clear redundancy beyond generic replication labels

The design mentions write replicas and read replicas, but it does not show how the API Gateway, Redis, or primary data store avoid single points of failure. At senior level, basic HA should be explicit: multiple stateless service instances behind the gateway, Redis with replication/sentinel or managed HA, and a database deployment with failover. Without that, the system has obvious availability gaps.

Scalability strategy is only partial

Read scaling is implied, but write scaling is not well thought through. URL generation depends on DB uniqueness checks and retrying collisions, which can become expensive under higher write concurrency. A stronger design would explain partitioning strategy or a more deterministic ID generation approach so writes do not bottleneck on repeated collision handling.