TinyURL — Naive Single-Server

URL shortening is the canonical easy system design interview question, and the naive single-server approach is where every discussion begins. The question sounds deceptively simple: given a long URL, generate a short alias; given the short alias, redirect to the original URL. Three components — a client, a service, and a database — are the absolute minimum to make this work. The naive approach deliberately omits every optimization to establish a measurable baseline.

This architecture runs a single ECS Fargate task (1 pod, 5 threads) that talks directly to a PostgreSQL RDS instance with 50 max connections. Short codes are generated using random UUIDs (first 7 characters of a v4 UUID), which avoids any need for a coordinated counter service or distributed lock. Every redirect lookup hits the database directly — there is no cache between the service and PostgreSQL, no CDN in front of the service, and no load balancer distributing traffic across replicas.

The educational value emerges under load. At 100 RPS, redirect latency is a comfortable 25ms and the database runs at 20% utilization. At 500 RPS, the service's 5-thread pool begins saturating (theoretical max is ~625 sustained RPS at 8ms processing time), and p99 latency climbs to 80ms. At 1,000 RPS, the system crosses a critical threshold: the database connection pool fills up, thread pool exhaustion causes request queuing, and p99 latency exceeds the 100ms SLO. At 10,000 RPS — a realistic peak for even a moderately popular shortener — the database is at 95%+ utilization and the system is effectively non-functional.

This is precisely the inflection point that interviewers want candidates to identify. The 100:1 read-to-write ratio in URL shortening means the database handles 100 reads for every write. Without a cache to absorb repeated reads for popular URLs, the database is the sole bottleneck for the entire read path. Run this variant side-by-side with the Counter-Based (v1) variant to see the dramatic difference: adding a Redis cache drops database utilization from 95% to under 15% at the same traffic level, because 95% of reads are served from cache instead of hitting PostgreSQL.

The naive URL shortener is a straight-line three-component architecture with zero branching, zero caching, and zero redundancy. Every request follows the same path: Client to UrlService to UrlDatabase.

For URL creation (POST /api/v1/shorten), the UrlService generates a random UUID and takes the first 7 characters as the short code. This requires no coordination — no counter service, no distributed lock, no consensus protocol. The service performs an INSERT into the urls table with a UNIQUE constraint on short_code. If an astronomically unlikely collision occurs (probability approximately 1 in 3.5 trillion for 7-char Base62), the INSERT fails and the service retries with a new UUID. The write path takes approximately 63ms: 8ms CPU processing + 5ms network + 50ms durable DB write.

For redirect reads (GET /api/v1/redirect/{code}), the UrlService performs a SELECT query on PostgreSQL using the short_code primary key. The B-tree index ensures O(log n) lookup time, completing in approximately 10ms at low load. However, every single redirect hits the database — there is no cache to absorb repeated reads for viral links. With a 100:1 read-to-write ratio, 90% of all requests are redirect reads, and every one of them goes to PostgreSQL.

The service runs on ECS Fargate with 2 vCPU, 4 GB memory, and only 5 threads. This deliberately constrained sizing creates a clear throughput ceiling at approximately 625 sustained RPS (5 threads / 0.008s per request). The PostgreSQL instance allows 50 maximum connections — once all are in use, new requests wait in a connection queue, adding queuing delay on top of base query latency.

There is zero redundancy at any layer. A service pod crash takes down 100% of capacity (not 17% as in the v1 variant with 6 pods). A database failure loses all data (no replicas). This simplicity is the point: three components, three failure modes, one obvious bottleneck.

Vertical scaling only. Upgrade the ECS task to more vCPUs and memory to increase service throughput. Upgrade the RDS instance to a larger class for more connections and I/O bandwidth. Both have hard ceilings: the largest ECS task is 16 vCPU / 120 GB, and the largest RDS instance handles ~10K connections. Horizontal scaling (adding pods) requires a load balancer, which fundamentally changes the architecture to the v1 variant. The naive design hits its scaling wall at approximately 500 RPS, after which you must add architectural components (cache, LB, replicas) rather than just scaling existing ones.

For the naive variant, monitoring focuses on the single database as the primary bottleneck. Key metrics: PostgreSQL active connections (alert at 40/50, critical at 48/50), query latency p99 (alert at 50ms, critical at 100ms), CPU utilization (alert at 70%, critical at 90%), disk I/O wait time, and WAL write throughput. Service-level metrics: thread pool utilization (active_threads / 5), request queue depth, error rate (5xx responses). Set up a dashboard showing database utilization vs. traffic RPS to identify the exact inflection point where the database becomes the bottleneck. At low traffic, all metrics are green — the value is running the simulation at increasing RPS to see when they turn yellow and red.

The naive architecture is the cheapest option at low traffic: one ECS Fargate task (2 vCPU, 4 GB) at ~$60/month + one RDS PostgreSQL instance (db.r7g.large) at ~$120/month = ~$180/month total. No load balancer, no cache, no CDN overhead. However, cost-per-request increases non-linearly as the database becomes the bottleneck — at 500 RPS, you are paying $180/month for a system near its limits. The v1 variant (counter + cache) costs ~$400/month but handles 20K RPS — a 40x throughput improvement for 2x the cost. The naive approach is cost-effective only below ~200 RPS sustained.

The naive variant has no authentication layer (no API Gateway). All endpoints are publicly accessible, making them vulnerable to abuse: automated URL creation to exhaust storage, redirect-based phishing, and open redirector attacks (using the shortener to disguise malicious URLs). Short codes are random UUIDs, which are not guessable — unlike sequential counters that leak creation volume. For production, add rate limiting (v1's API Gateway), URL validation (block known malicious domains), and abuse detection. HTTPS should be enforced at the service level since there is no CDN or gateway to terminate TLS.

Deployment is straightforward: a single ECS task definition with one container. Rolling updates replace the old task with a new one, causing 30-60 seconds of downtime during the swap (no load balancer means no graceful draining). For zero-downtime deploys, you need at least two pods behind a load balancer (v1 variant). Database schema changes require careful handling — run migrations before deploying new code since there is only one database instance. Rollback: revert the ECS task definition to the previous version. There is no blue/green capability without a load balancer.