Scaling Reads hard
In a high-throughput Redis cache, your CPU is at 100% despite low network usage. You are storing large JSON blobs. What is the likely culprit?
- A Redis is swapping to disk.
- B Serialization/Deserialization overhead in the application, or compression overhead if enabled.
- C Redis single-threaded architecture.
- D Too many connections.
Answer: B. Serialization/Deserialization overhead in the application, or compression overhead if enabled.
Often overlooked: converting a 1MB Object to JSON (and back) consumes significant CPU cycles. If done 10,000 times/sec, the app server (or Redis if using modules) chokes on string manipulation.
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?