URL Shortener: Interview Guide

The following topics contain open-ended architectural questions without prescriptive solutions. They are designed for staff+ conversations where you demonstrate systems thinking, trade-off analysis, and strategic decision-making.

301 vs 302 Redirect Strategy

Level: Staff

Context: Your URL shortener serves both external marketing campaigns and internal employee tools. Product and engineering teams need to understand redirect behavior implications for different use cases.

Discussion Points:

1. When would you choose 301 (permanent redirect) vs 302 (temporary redirect) and why?
2. For an internal application, why is 301 better? How does it reduce server load?
3. What are the browser caching implications of 301 vs 302 for both user experience and analytics?
4. How does redirect choice affect click tracking and analytics accuracy?
5. What happens if you need to change the destination URL after using 301? How would you handle migration?
6. What organizational processes ensure the right redirect type is chosen for each use case?

Multi-Region Deployment and Global Consistency

Level: Staff

Context: A user in California creates a shortened URL. Seconds later, a user in Asia tries to access it. The URL returns 404. Your support team is flooded with complaints about "broken links."

Discussion Points:

1. What is the replication latency across regions when a URL is created in one region and accessed from another?
2. How long is the acceptable lead time before the URL is usable across the globe?
3. How do you design for acceptable user experience during replication lag without compromising write latency?
4. What trade-offs exist between strong consistency guarantees, eventual consistency, and write performance?
5. When would you choose synchronous cross-region replication vs eventual consistency?
6. How would you communicate these trade-offs to product and business stakeholders?

Service Health Monitoring and Failure Detection

Level: Staff

Context: It's 3 AM. Your on-call phone rings. The URL shortener is "broken" but monitoring shows all green. How do you know what's actually wrong and where to look?

Discussion Points:

1. What are all the ways this service can break down? (database failure, cache failure, ID generator failure, network partitions, DNS issues, region outages)
2. How do you detect each type of failure before users report it? What metrics and alerts would you implement?
3. What monitoring and alerting strategy distinguishes between partial failures vs complete outages?
4. How do you measure the "health" of the service from the user's perspective vs internal systems?
5. What's your incident response playbook for each major failure mode?
6. How do you handle cascading failures across components (e.g., database slow → cache overload → API timeout)?

Malicious URL Detection and Prevention

Level: Staff

Context: Security vendors have blocklisted your domain because phishing campaigns are using your URL shortener. Legitimate users can no longer share links. Revenue is dropping. The exec team wants answers.

Discussion Points:

1. How would you detect and prevent malicious URLs from being created in the first place?
2. What are the trade-offs between real-time URL scanning (adds latency to shortening) vs batch scanning (allows malicious URLs temporarily)?
3. How do you handle false positives that block legitimate URLs? What's the user impact and support burden?
4. What happens to existing malicious URLs that get reported after creation? How quickly can you take them down?
5. How do you prevent your domain from being blocklisted by security vendors and email providers?
6. What's the balance between security measures and user privacy (e.g., scanning destination content)?

Key Design Decisions

ID Generation: Machine ID + Sequence Number produces the shortest codes (6 characters) with guaranteed uniqueness and no runtime coordination. Alternative approaches (hash, UUID, Snowflake) either produce longer codes or require collision detection.

Encoding: Base62 (a-z, A-Z, 0-9) avoids URL-encoding issues from special characters while providing 56.8B capacity in just 6 characters — 30× our 5-year storage requirement.

Caching: Read-through + write-through hybrid achieves 90%+ cache hit rate. With Zipfian access distribution, 1 GB of Redis cache (~2M URLs) handles 93% of traffic, reducing database load to ~80 QPS.

Redirect Strategy: 302 (temporary) over 301 (permanent) preserves analytics accuracy and URL deactivation capability. A short Cache-Control: max-age (for example 5 minutes) is the middle ground: it absorbs repeat clicks, at the cost of counting at most one click per user per window.

Sharding: Not needed at today's volume (one primary with read replicas is enough). When one primary is outgrown, the machine ID prefix becomes the shard key: zero-coordination writes, each server writes to its own shard, and read routing extracts the prefix from the short code. No rebalancing is needed when adding shards.

Analytics: Two-tier counting (Redis HINCRBY for every click, a 60-second flush to the database) counts in sub-millisecond time without touching redirect latency; each flush collapses repeat clicks into one row update per link and applies each batch exactly once.

Architecture Principles Applied

Common Pitfalls to Avoid