URL Shortener — system design by SwiftJaguar63

Quality attributes are too vague to guide design

You mention only 'Scalability >> availability'. What latency, durability, or consistency expectations does the system actually need to meet? Without at least naming the key attributes and their importance, the design has no way to justify trade-offs such as whether redirects must stay fast during load spikes or whether expired links can be served briefly after deletion.

No concrete targets for scale or availability

Have you considered what happens when someone asks whether this design supports 10K requests/day or 100K requests/second? 'Scalability' and 'availability' are priorities, but there are no measurable targets like QPS, p95 latency, or uptime. Without numbers, it is impossible to tell whether the proposed approach is sufficient or overbuilt.

Consistency model is not stated

What happens if a short URL is created and an immediate read follows from another replica or cache? Without explicitly choosing and justifying a consistency model, you cannot reason about whether users may see 'not found' right after creation, whether expiry is enforced exactly at the deadline, or whether one-to-one mapping can be violated under concurrent writes.

NFRs are not connected to the stated assumptions

The requirements include URL shortening with one-to-one mapping and optional expiry, but the NFR section does not tie its priorities to any workload assumptions. You could improve this by stating expected read/write ratio, traffic growth, and expiry behavior, then explaining why scalability matters more than availability for that workload and what level of inconsistency is acceptable.

Expiry is mentioned in requirements but not modeled as an entity relationship or state on the URL mapping

Have you considered what happens when a shortened URL reaches its expiration time? Without modeling expiry as part of the URL-to-shortcode mapping, the core happy path cannot clearly answer whether a redirect should still resolve or be rejected. You could improve this by making it explicit that a URL mapping has an expiration policy or expiry timestamp associated with it.

Relationship between URL and shortcode is not clearly defined

You list both 'url' and 'shortcode', but how do they connect in the one-to-one mapping requirement? If that relationship is not explicit, it becomes ambiguous whether one URL can have multiple shortcodes over time or whether one shortcode can ever be reassigned. You could strengthen this by stating clearly that a shortcode maps to exactly one URL mapping record, and vice versa if strict one-to-one is required.

No traffic model from users to QPS

Have you considered translating expected usage into create-vs-redirect load? A URL shortener is typically read-heavy, and the sizing of the datastore, cache, and network path depends on that split. Without a rough peak QPS model, it is unclear whether the design can handle redirect spikes or bursty link access patterns.

No storage growth estimate

Have you considered how many new short URLs are created over time and how expiry affects retained data? Even simple assumptions like links/day, average record size, and retention window would let you estimate whether storage stays small, grows steadily, or needs partitioning/archival.

No peak-load or hotspot analysis

What happens when a single shortened URL goes viral and receives a sudden burst of redirects? Without any discussion of peak traffic, cache hit expectations, or hotspot behavior, the design gives no confidence that it can absorb uneven access patterns common in URL shorteners.

Protocol choice is unclear

Have you considered how clients are expected to interact with the service? For a URL shortener, this is typically a mix of HTTP redirect behavior for resolution and a REST-style create endpoint for shortening. Without stating the protocol, redirect semantics, caching behavior, and client integration are all ambiguous.

No resource or URL design to validate

Have you considered what the public and management surfaces look like? For example, clients usually need a route to create a short URL and a separate path-based route to resolve a short code. Without any route structure, it is impossible to judge whether the API is clean, resource-oriented, or even supports the one-to-one mapping requirement.

Error handling and retry behavior are unspecified

What does the client see if the submitted URL is invalid, the alias already exists, the short code is expired, or the code is not found? Without status codes or an error shape, clients cannot distinguish bad input from retryable failures, and integrations become brittle.

Expiry handling is not reflected in the architecture

The requirements say links can have expiry, but what happens when an expired shortcode is requested? The design does not show whether expiry is stored with the URL record, checked on reads, or cleaned up asynchronously. Without that, expired links may continue to resolve or require inefficient scans.

Redis counter is a likely bottleneck and single point of failure

What happens when the Redis counter is unavailable or saturated? If every new short URL depends on a single counter service, URL creation can stop entirely. At the stated priority of scalability over availability, this is the first component I would push on; you would want partitioned ID generation, preallocated ranges, or a clearly replicated/failover strategy.

No caching on the hot lookup path

URL shorteners are typically read-heavy on shortcode resolution. Have you considered what happens when a popular shortcode is repeatedly looked up? Without a cache in front of DynamoDB for redirects, the database becomes the hot path for every access and will take unnecessary load.