Design a URL Shortener, stage 5 of 9: decide
Make redirects fast far from the servers
Nothing is overloaded, but users in Sydney are waiting. Work out why before choosing a fix.
System so far· 5 parts
Select a component to see what it is responsible for and which state it owns.
- 1Redirect service → Postgres: Look up code
- 2Customer dashboard → Links API: Create, edit, disable
- 3Links API → Postgres: Insert with unique code
What you need to know
0 of 2 checks done
Two different things make a request slow:
- Load: a component is too busy, so requests queue. You see high CPU, long queues or many open connections.
- Latency from distance: data takes time to travel. Light in optical fibre covers about 200 km per millisecond, and nothing goes faster.
They need different fixes, so diagnose first.
Work it out
Sydney to the US East Coast is about 16,000 km. What is the fastest possible round trip, there and back, in milliseconds?Check
The database is at 20% CPU, the redirect service at 30%, and Sydney sees 280 ms. What's the bottleneck?The only fix for distance is to answer from somewhere closer:
- Cache at the edge. A CDN has servers in Sydney. They can keep a copy of a redirect for a short time and answer it locally in a few milliseconds.
- Run a copy of the service nearby. Put redirect servers and a read replica of the database in Asia-Pacific.