Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Load Balancer: AWS ALBs are managed and multi-AZ by default, but you should explicitly state you're deploying across multiple Availability Zones, not just one

App servers: run at least 2-3 instances across different AZs, behind the load balancer, with auto-scaling group health checks so a failed instance gets replaced automatically

DynamoDB: this is actually already highly available by default — it automatically replicates data across multiple AZs within a region. Worth saying this explicitly rather than assuming the interviewer knows you know it.

Redis/ElastiCache: by default, a single Redis node is a single point of failure. Fix: use ElastiCache with Multi-AZ replication — a primary node plus replica(s), with automatic failover if the primary goes down.

Cross-region: for true disaster recovery (not just AZ failure), you could replicate DynamoDB globally using DynamoDB Global Tables, though this adds complexity/cost — worth mentioning as an option, framed as "if the business requires surviving a full region outage."

Load Balancer

Job: distributes incoming requests across multiple app server instances so no single server gets overwhelmed
Why needed: enables horizontal scaling — as traffic grows, you add more app servers behind it rather than making one server bigger
AWS mapping: Application Load Balancer (ALB)

2. Application Servers

Job: stateless compute layer that handles the actual request logic — validates input, talks to the ID Generator on writes, checks cache/DB on reads
Why stateless matters: any server can handle any request, which is what makes horizontal scaling and auto-scaling possible — no server holds session-specific data
AWS mapping: given our earlier discussion, this fits well on Lambda (unpredictable traffic, minimize idle cost) or ECS/EKS if you expect steady baseline load

3. ID Generator Service

Job: produces a guaranteed-unique, incrementing number for every new short URL created, which then gets base62-encoded into the short code
Why it's its own component, not just logic inside the app server: if you have multiple app servers creating URLs simultaneously, they'd race to generate the same number unless there's one authoritative source of truth for "what's the next number." This is a classic distributed coordination problem.
Real implementation options: a dedicated counter service backed by a strongly-consistent store, or pre-allocating ID ranges to each app server (e.g., server A gets 1-1000, server B gets 1001-2000) to avoid a bottleneck on every single write

Pre-allocated ID ranges (simplest, most common answer): each app server requests a block of IDs upfront from a coordinator (e.g., "give me IDs 5000-5999"), then hands them out locally without needing to call the generator on every single request. If a server crashes with unused IDs in its block, those IDs are simply wasted — acceptable trade-off, since ID space is effectively infinite. This avoids split-brain entirely because ranges are only ever assigned once, from one authoritative store (e.g., a single row in DynamoDB with a conditional atomic increment).

Distributed ID generation without central coordination (alternative): use something like a Snowflake-style ID (timestamp + machine ID + sequence number combined) — no central generator needed at all, each server can generate unique IDs independently. Trade-off: IDs are longer/less clean than a simple incrementing counter, so your "short" URL isn't quite as short.

4. Cache Layer (Redis/ElastiCache)

Job: stores the hottest short_code → long_url mappings in memory, so repeated reads for popular links don't hit the database every time
Why needed: given our 100:1 read-heavy ratio and the "hot key" problem (viral links), this is what keeps read latency low and protects the database from load spikes
Pattern used: cache-aside — check cache first, on miss go to DB and populate cache

Cache miss handling: this is the cache-aside pattern we already named — on a miss, the app server queries DynamoDB directly, gets the long_url, writes it into Redis, then returns the redirect to the client. Worth stating explicitly that this write-back-on-miss step exists, since the earlier answer implied it but didn't spell it out.

TTL (Time To Live): you don't want the cache growing forever — set a TTL per cache entry (e.g., 24 hours), after which Redis automatically evicts it. If that link is still popular, the next request just re-fetches from DynamoDB and re-populates the cache — a brief moment of extra latency, not a failure.

Eviction policy: also worth naming — Redis supports policies like LRU (Least Recently Used) for when memory fills up, evicting the least-recently-accessed entries first, which naturally keeps your "hot" links cached and lets cold ones fall out.

5. Database (DynamoDB)

Job: the durable source of truth for every short_code → long_url mapping, ever created
Why DynamoDB specifically: simple key-value access pattern, no joins needed, needs to scale to potentially billions of rows with fast, predictable reads — exactly DynamoDB's sweet spot

6. CDN (CloudFront) — optional/enhancement layer

Job: caches redirect responses at edge locations geographically close to users, reducing round-trip latency for users far from your primary AWS region
Why it's separate from Redis: Redis solves "which links are hot," CDN solves "where is the user physically located" — two different latency problems

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10