Scaling Reads hard
Your API serves different JSON content based on the `User-Agent`. You configure your CDN to respect `Vary: User-Agent`. What is the likely performance impact?
- A The Cache Hit Ratio drops drastically because there are thousands of unique User-Agent strings (browser versions, OS versions), effectively fragmenting the cache into thousands of tiny buckets.
- B Performance improves significantly.
- C The CDN ignores the header.
- D Security increases.
Answer: A. The Cache Hit Ratio drops drastically because there are thousands of unique User-Agent strings (browser versions, OS versions), effectively fragmenting the cache into thousands of tiny buckets.
Varying on high-cardinality headers is a classic anti-pattern. Ideally, you should normalize the User-Agent at the edge (e.g., convert to `X-Device: Mobile` or `Desktop`) and Vary on that custom header.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a caching system, what is a 'Cache Miss'?
- Why is `SELECT * FROM Users` generally discouraged in high-performance applications compared to `SELECT name, email FROM Users`?
- You have users all over the world downloading large images from your server in New York. Users in Australia complain it is slow. What solves this?
- What is the main downside of reading from a Read Replica instead of the Primary database?
- You have maximized the RAM on your single database server, but it's still too slow. You decide to add 10 more servers to share the load. What is this called?
- You have 5 Read Replicas. How does the application know which one to ask for data?