URL Shortener Interview Questions

I would start with numbers. Suppose 100 million new URLs a month, about 40 QPS write, reads much higher, say 10x. Redirects must be fast. Custom aliases and expiry are optional — I would ask. API: POST /shorten with a long URL returns a short code. GET /{code} returns 302 to the long URL. I use 7 character base62 codes, which is enough for a huge keyspace. I generate IDs with a range allocator or hash plus retry on collision. I store code to long URL in a key-value store. Redis in front for hot redirects. I would not unique-index the long URL unless they want one short link per URL. I add rate limits and abuse checks because this will get spam. 301 vs 302: 302 if I still want to count clicks on my servers. I would draw client, API, cache, DB, and a small ID service.

I would not hash the URL and hope. I would use a unique id from Redis INCR or a Snowflake-style id, then encode it in base62. That gives unique codes without a collision loop. If they want custom aliases I store those in a separate unique index and reject duplicates. I would mention that hashing the long URL can collide and also maps the same URL to one code, which may or may not be what product wants. I ask whether the same long URL should reuse a code.

Writes go to an id generator plus a datastore keyed by short code. Reads of popular codes should hit a cache and maybe an edge cache or CDN for the redirect. I would keep the redirect path tiny: lookup, 301 or 302, done. Analytics is async — I would not write click stats on the hot redirect. Partition by short-code hash. If one celebrity link is hot, the cache saves the database. I would put a rate limit on create so people cannot exhaust the id space.

301 is cached by browsers, so the user may never hit us again. That is good for latency and bad if I need click counts or I might change the destination. 302 keeps traffic coming through our servers so I can log and update. Product shorteners that care about analytics often use 302. I would ask what we optimize: analytics versus client-side cache. I would not pick 301 by default just because it sounds 'permanent'.

Expiry is a TTL field and a sweeper or lazy delete on read. Custom aliases need a unique constraint and a reserved-word list so nobody takes 'login'. Abuse: rate limit create per IP and API key, captcha on public UI, and malware URL checks against a blocklist. I would not skip abuse — open shorteners get used for phishing. That sentence is worth saying in an India product interview because they have seen it.