Helpful Numbers for Designing Technical Systems
When I design a new service, I want it to be efficient. Mostly, for any humans involved, but also for the technical components. Why make two HTTP calls when you can make 1. When thinking about tradeoffs it can be helpful to consider how long common operations take.
Not surprisingly, lists have been made of these common operations. As far as I can tell starting with Peter Norvig, and then re-popularised by Jeff Dean. 1 They are sometimes referred to as latency numbers every engineer should know. I take issue with the “every programmer should know” language, but as you advance in your career it’s helpful to know these so that you can reason about service design.
For instance, if you are designing a service that would redraw the screen every time a character was typed you might not want to wait for a response from a remote system. The reason being, a network response will never be fast enough. And it would feel incredibly slow for the person typing. If you can reasonably think through service design earlier in the design process it will be much cheaper for everyone involved. These numbers can help you make these kinds of decisions much earlier in a design process.
Here’s a nice image version:
There is also an interactive version of this that shows how these numbers have changed overtime. 3
Finally, its fun to see these numbers and think about them, but if you want to learn them and really incorperate them I would recomend this interactive exercise built by Julia Evans, “Computers are Fast”.