DrawLint.aiURL Shortener — system design by AgileViper46
Lean No HireReviewed by 6 specialized AI reviewers. Explore the diagram and the full per-section feedback below.
Loading diagram…
The candidate demonstrates reasonable fundamentals and some good architectural instincts, but the design is not senior-complete. Critical gaps in the actual data flow, HA story, and capacity-to-architecture translation weaken confidence that they can take this from a plausible sketch to a production-ready scalable system.
NFRs are mentioned but not measurable enough
You list latency and availability goals, but only latency has a rough target and even that is phrased as 'ideally'. For a senior-level design, make these explicit and testable, e.g. redirect read p99 < 100ms, create short URL p99 < 200ms, availability 99.99% for redirects and 99.9% for writes.
Availability target is not quantified
Saying the system should be 'highly available' is too vague to evaluate or design against. Define a concrete SLA/SLO, such as 99.99% availability for resolving existing short URLs, and optionally a separate lower target for URL creation if reads are more critical.
Consistency requirement is underspecified
You correctly call out the need for 1 short code -> 1 long URL mapping consistency, but you do not state the consistency model. A senior answer should explicitly say whether this mapping requires strong consistency on writes/reads to prevent duplicate or conflicting mappings, while allowing eventual consistency only for non-critical derived data like analytics.
Scalability requirement is too generic
The statement 'scalable for the users' does not provide enough guidance for capacity planning or tradeoff decisions. Tie scalability to the stated assumptions with concrete numbers such as expected DAU, peak QPS, read/write ratio, storage growth, and traffic burst factor.
Numbers are not tied to assumptions
The NFRs are not anchored to any workload assumptions, so it is hard to judge whether the targets are realistic or sufficient. For senior-level quality, specify targets in the context of expected scale, for example: at 50K peak redirect QPS and 100:1 read/write ratio, maintain p99 < 100ms and 99.99% read availability.
Core nouns for a URL shortener are identified
The design includes the two primary domain entities needed for the basic flow: a User and a URL mapping object. For a simple URL shortener, these are the central nouns the system operates on.
Relationships between entities are not explicitly defined
The entities are listed, but the cardinality is not stated. At Senior level, the design should explicitly define that a User has a 1:N relationship with UrlMap and that each UrlMap belongs to one User when created by an authenticated user. Add the relationship definitions directly to make ownership and lifecycle clear.
Core traffic numbers are present
The design includes DAU, calls per day, read QPS, peak read QPS, write QPS, and a read:write ratio. That gives a usable starting point for capacity planning instead of staying purely qualitative.
Storage estimate is in the right rough ballpark
Estimating per-mapping size and extrapolating to 1B URLs shows an attempt to connect object size to total storage. For a high-level interview estimate, ~150GB for 1B small mappings is a reasonable first-order calculation before replication and indexing overhead.
Calculations stop too early
The numbers do not form a full methodical chain from traffic to storage and bandwidth. You have DAU -> daily calls -> QPS, but you do not estimate network throughput, cache hit impact, database IOPS, replication overhead, retention growth over time, or storage including indexes and replicas. To make this senior-level, continue the math through read/write bandwidth and persisted storage after replication.
Peak assumptions are too shallow for 100M DAU
Using only 2x average as peak is weak without justification. At this scale, regional concentration, diurnal traffic, and hot-key effects can make peak materially higher than 2x. Add a stated peak factor and show how sensitive QPS and backend capacity are to that assumption.
Write estimate is not clearly derived from the workload
The write QPS is assumed as 1/10 of reads, but that ratio is asserted rather than tied to user behavior or product flow. For capacity planning, explain why writes are 10% of reads and whether writes represent new URL creation only. If the ratio is an assumption, call it out explicitly and show how the system changes if it is 1:20 or 1:5 instead.
Storage estimate omits real overheads
The 150B per mapping estimate likely excludes metadata, indexing structures, replication factor, tombstones/deletes, and operational headroom. Raw data size alone understates actual storage needs. A better estimate would separate logical row size from physical storage and multiply by replication plus index overhead.
No evidence that infrastructure sizing matches the numbers
The section gives traffic estimates but does not translate them into required capacity per tier, such as how many cache nodes, database shards/partitions, or expected per-node QPS. At senior level, the calculations should justify whether the proposed high-level design can actually sustain 25k read QPS and 1.2k write QPS.
Read QPS math is correct but should show the formula
1B requests/day is about 11.6k QPS, so the 12k estimate is fine. However, writing the formula explicitly improves rigor and makes it easier to validate the rest of the sizing: QPS = daily requests / 86,400.
Core create and resolve endpoints are present
The API includes the two essential routes for a URL shortener: creating a short URL with POST /api/v1/urlmaps and resolving a short code with GET /api/v1/urlmaps/{short-id}. This covers the primary functional flow cleanly.
Resource-oriented REST path structure
Using a versioned, noun-based path like /api/v1/urlmaps is a solid REST convention. It keeps the API organized and extensible if additional operations on shortened URLs are added later.
Response semantics for redirect endpoint are underspecified
The GET /api/v1/urlmaps/{short-id} route is described as returning 'LongUrl 302 redirect', which mixes data retrieval and redirect behavior. For a redirect API, the response should be clearly defined as an HTTP 302/301/307 with a Location header, not a body containing the long URL. Specify the exact redirect contract so clients know what to expect.
Create response contract is incomplete
POST /api/v1/urlmaps mentions 200/201 and returning ShortCode, but the response shape is not defined. A senior-level API should specify a consistent response body, such as shortCode, shortUrl, longUrl, expiration, and createdAt, and clarify when 200 vs 201 is used. For example, use 201 for successful creation and reserve 200 only for idempotent alias reuse if that behavior is intended.
Missing error handling details and status codes
Only 404 is mentioned for lookup and 200/201 for create. Important failure cases are not defined, such as 400 for invalid URL format, 409 for alias collision, and possibly 410 if an expired short URL is accessed. Define error status codes and a standard error response body so clients can handle failures predictably.
CRUD coverage is minimal beyond the core flow
The primary create and read/resolve operations are covered, which may be enough for the stated requirements, but there are no update or delete routes for the primary resource. If the functional requirements include managing expiration or aliases after creation, add PATCH/DELETE endpoints; otherwise this is acceptable but should be explicitly intentional.
Request field naming and format should be tightened
The request body uses mixed naming like longUrl, expiration, and alias(customShortUrl), and expiration is marked as 'time-date-format ??'. Define a precise schema with stable field names and formats, such as expirationAt in ISO-8601 format and alias as a plain optional string, to avoid ambiguity for clients.
Reasonable read/write service split
Separating read and write paths is a solid HLD choice for a URL shortener because it matches the access pattern: redirects are read-heavy while creation is write-light. This gives a clean path to scale each side independently under the stated assumptions.
Deterministic short-code generation approach
Using a global counter with base62 encoding is a valid way to generate compact unique short codes, and the note about assigning ranges via ZooKeeper shows awareness of reducing contention on a single ID generator.
Cache included for redirect lookups
Adding Redis with TTL/LRU for short-code resolution is an appropriate optimization for a read-dominant redirect workload and can significantly reduce database pressure if wired into the read path.
Read-path cache is not actually connected in the design
Redis is present as a component but has no connection from the read service, so the end-to-end data flow does not show how cached redirects are served. As drawn, all reads go directly from Read service to Postgres. Add explicit Read service -> Redis and Redis miss -> Postgres flow, plus optional cache fill after DB lookup.
Multiple duplicate services are orphaned
There are repeated 'Write service' and 'Read service' nodes with no connections. Orphaned components make the architecture ambiguous and suggest the scaling story is unfinished. Either remove the duplicates or show them as replicated instances behind the load balancer with clear connectivity.
Database is a clear single point of failure
Only one Postgres instance is shown, and both reads and writes depend on it. For a senior-level HLD, basic redundancy should be explicit: primary-replica setup, failover strategy, and ideally read replicas for redirect traffic if the assumptions require scale.
Global counter service can become a bottleneck or SPOF
Even with range assignment noted, the design still centers ID generation on a single logical counter service without showing replication, failover, or how range leasing works operationally. Make the range allocator highly available and show workers generating IDs locally from leased ranges to avoid per-request dependence on a central counter.
CDN is not integrated into the main redirect flow
Users connect to the CDN, but there is no connection from CDN to the read service or explanation of what content the CDN serves. For a URL shortener, CDN is only useful if it fronts redirect responses or static assets. Clarify whether CDN caches 302 responses or remove it to avoid an orphan-like component.
No async path for non-critical side effects
The core create and redirect flows can work synchronously, but a senior design usually calls out asynchronous handling for heavy or non-user-blocking work such as analytics, click logging, or expiration cleanup if those exist in scope. If such workloads are expected, add a queue/stream and background workers so the redirect path stays fast.
Want this kind of feedback on your own design?
Draw your architecture for URL Shortener and get an instant hire/no-hire signal from 6 specialized AI reviewers — free to start.