The interview framework

A design question is deliberately open: "Design a link shortener." Without structure it is easy to jump to boxes, run out of time, or miss something obvious. A fixed order of steps keeps you calm, shows your thinking, and makes sure every decision is justified by something you wrote down earlier. You have about 40 minutes, so spend them on purpose.

Clarify the scope first. Ask what the system must do and what it can ignore. For a link shortener: can users choose their own alias, do links expire, do we need analytics? Write down functional and non-functional requirements, and say what is out of scope.

Then define the interface. Create one endpoint per functional requirement. Name the method, the path, the inputs, and what comes back.

• POST /links with the long address, an optional alias and an optional expiry returns 201 and the short link.
• GET /{key} returns 302 with a Location header pointing at the long address.
• DELETE /links/{key} removes a link, if the owner is signed in.

Writing the interface early forces precision. It also reveals requirements you missed, which is the loop from the first lesson at work.

Run the numbers from the previous lesson: writes per second, reads per second, storage, bandwidth and cache size. State each assumption. These numbers justify every later choice.

Then design the data. List the entities, their fields, and how they relate. For our service the main entity is a link with a key (the primary key), the long address, a creation date, an expiry date and an owner.

Choose the store from the shape of the data. We have billions of small rows, no joins, and every read is a lookup by key. That fits a key value or wide column store well. A relational database is also defensible for the small user table. Say which you picked and why.

High-level design is the simplest picture that meets the requirements: client, application servers, database. Draw it first and talk through one write and one read.

Detailed design is where you spend the most time. Pick the two or three hardest parts and go deep. For us that is how to generate unique keys without collisions, how to split the data across machines, and where a cache helps. Explain alternatives and say why you chose one.

A good rule: breadth first, then depth where the risk is. Do not polish an easy box while a hard one is still empty.

Look at your own design as a critic. Where is a single point of failure? What happens when a server, a disk or a whole data center dies? Which part will saturate first when traffic doubles? Add replication, a pair of load balancers, monitoring, alerts and cleanup of expired data where needed, and mention security and rate limiting.

A sensible time budget for about 40 minutes:

• Requirements and scope: 5 minutes.
• Interface: 3 minutes.
• Estimation: 4 minutes.
• Data model: 4 minutes.
• High-level design: 8 minutes.
• Detailed design: 10 minutes.
• Bottlenecks and wrap-up: 5 minutes.

The goal is not a perfect answer. It is a clear, justified one, where every box exists because of a requirement or a number you wrote down.