Design Deep Dive: URL Shortener + Pastebin
In this lesson we practice answering a classic interview question: building a "URL shortener" (a service that takes a long web address and gives back a short one, like bit.ly). We talk in plain terms about how the service receives requests (an API — the way programs talk to each other), how we store
System Design (planning how to build large software that works) is like planning a city: roads that move the traffic, warehouses for storage, traffic lights that manage the load, and maintenance crews that fix problems — so the city keeps running smoothly even during the busiest rush hour.
- Classic deep dive
- The classic question practiced in this lesson: designing a "URL shortener" like bit.ly. We walk through how requests come in (the API), how data is stored (the schema — the table's shape), how the short code is created (ID generation), how we speed things up with fast memory (a cache), and how we grow to many users (scale).
- Trade-off
- A trade-off is a deliberate choice between two good things when you cannot fully have both — like choosing between fast and cheap. There is always a price, and in an interview you say it out loud to the interviewer.
- Operational metric
- A number that shows whether the decision really works for real users (in production — the live system). For example: latency (how long it takes to get an answer), error rate (the share of requests that fail), queue lag (how much work has piled up waiting in line), or cache hit ratio (how often the fast memory already had the answer).
