EP9: Learning System Design | URL Shortener | Part 1 Asking Better Questions
Using the FUNCS framework to gather requirements before system design
Howdy friends,
This week I did not build anything.
But I learned how to think.
From my recent posts and tweets you might have seen that I have been learning system design using Amazon Q. I asked it to act like an interviewer while I act like the candidate, and we started with a simple problem: build a URL shortener.
I have not built the application yet. Building will come later. First I wanted to learn how to design.
And the first lesson surprised me.
The interviewer said, “Design a URL shortener.”
Earlier I would immediately start drawing architecture. Database, cache, load balancer, done.
But now I realized something important. The question is incomplete.
Good system design does not start with architecture. It starts with questions.
I struggled here.
I did not know what to ask or how to ask. That is when I learned a simple framework that changed my thinking.
F U N C S Framework
A simple structure for gathering requirements before designing anything.
F — Features
What exactly are we building
Should the short link expire
Should we support analytics
Should users create custom URLs
U — Users and Scale
How big is the system
Millions of users or billions
Is the system read heavy or write heavy
N — Non functional requirements
How good should the system be
Latency, availability, durability, security
C — Constraints
What limits us
Budget, technology, compliance, timeline
S — Success metrics
How do we know the system is good
Latency, uptime, cost, growth
At first, questions did not come naturally. But once I started thinking through this framework, better questions started appearing.
For example, under Features
A URL shortener creates a short link and redirects to the original URL. But should we track how many people clicked the link. Should we provide analytics. Should links expire.
Similarly, under Users and Scale
After estimating some rough numbers, I was able to do quick back of the envelope calculations.
Example
Writes around 35 per second so we provision for 50 with buffer.
Reads around 350 per second so we provision for 400 with buffer.
This small exercise helped me understand system size, capacity planning, and early design decisions.
I was genuinely happy that I could think this way. Asking better questions started shaping the design naturally.
This week was about learning how to ask before learning how to build.
In the next part, we will explore the real engineering challenge.
How do we generate short URLs that scale to billions of users.
Growing into a better cloud architect everyday.
Hope this was helpful. See you in the next episode.
Alon