Make them commit to numbers
Make your interviewer commit to numbers first, because a shortener for a marketing team and one for a social network are different systems.
Take a reasonable brief: 100 million new links a month, links that live for years, redirects that feel instant worldwide, and per-click analytics would be nice.
Do the arithmetic out loud. A hundred million writes a month across 30 days of seconds is about 40 writes a second. Trivial. One relational database yawns at that.
Look at the reads, because that is the story. Shorteners are pathologically read-heavy, often a thousand reads per write once links circulate. So 40 writes a second implies around 40,000 redirects a second, with spikes far above when one link goes viral.
Take that ratio, not the raw volume, as your design driver. Your write path can be boring. Your read path has to be cached and replicated.
Storage is not the problem
Storage stays small. A row is a code, a long address of maybe 500 bytes with indexes, a creation time and an owner. A hundred million rows a month for five years is 6 billion rows, roughly 3 terabytes, which fits on one large disk.
Say that out loud, because it surprises people. This is not a big-data problem. It is a hot-data problem.
Write down your non-functional requirements before you draw anything. Redirects under 100 milliseconds at the slow percentile, because your shortener sits in front of every page it serves.
State the asymmetry and collect the credit for it. Availability matters more than consistency here: serving a redirect from a cache ten seconds stale is fine, and returning errors breaks every link you have ever issued. That is what justifies the aggressive caching later.
Worked example
Nadia is asked to size a shortener for a ticketing company that texts links to buyers. Marketing says 2 million texts on a big on-sale day. She works it through: 2M links created over an 8 hour window is about 70 writes per second, fine for one database. Each buyer clicks 2 to 3 times (opens, reshares, second device), and clicks cluster in the 10 minutes after a text blast, so she budgets 2M x 3 / 600 seconds, about 10,000 redirects per second in bursts. Storage for a year of campaigns is 500M rows, around 250 GB. Her conclusion in the design review: one writer database, a Redis cache sized to hold every active campaign's links (a few GB), and read replicas for cache misses. Nobody argues, because the numbers are on the whiteboard.