Often you might come across these funny numbers which some authors assure it’s pretty important to know about. They don’t make sense until you need to do back-of-the-envelope calculations.
How do you decide whether proposal A or proposal B is faster? You will think in terms of time. One system uses a remote Postgres as a key-value data store served behind a web service via a monolith and the second uses a local Redis served via a micro service architecture. To answer questions like these, first, it is imperative to know how systems work. It is sufficient to know the big components abstracted. If you are a fan of reading OpenSource codebases, this should be even easier. A monolith for example is faster than microservices just by examining network trips. In-memory access is faster than a remote call + writing to memory/disk as Postgres has a server on top of the engine.
You can gauge an answer based on network trips, memory, and disk access. Now let’s say you want to have concrete values to base your estimates on? That’s where these funny numbers come in. They pin down a number on the operations. Reading an image for example is equal to disk seek + time to read the image. Guessing the time taken to transfer it is just the filesize / transfer rate, and so on.
The first person I saw talking about back-of-the-envelope calculations was Jeff Dean. Great chap!