Must know numbers for every computer engineer

6 min readSep 14, 2019

In 2010, Jeff Dean from Google gave a wonderful talk in Standford & he discussed few numbers of computing systems, he got really famous for that. Peter Norvig published those numbers for the first time in the internet. Time passes away, so the numbers also change. I found a very good interactive web UI of those numbers which roughly tell how much those numbers have changed over the years as a function of time.

This article is a compilation of not only Jeff Dean’s estimated data, rather of all such numbers from different sources which may help you as a system designer & architect. While designing, you can use these numbers to estimate the amount of resources your system needs.

Rough estimation of latency data for 2019:

L1 cache reference: 1 nanosecond.
L2 cache reference: 4 nanosecond.
Mutex Lock / Unlock: 17 nanosecond.
Main memory / RAM reference: 100 nanosecond.
Compress 1 KB with Zippy (currently called Snappy): 2000 nanosecond or 2 microsecond.
CPU branch mispredict: 3 nanosecond.
Solid State Drive (SSD) random read: 16 microsecond.
Disk (Hard drive / magnetic drive) seek: 3 millisecond.
Read 1,000,000 bytes sequentially from main memory: 4 microsecond.
Read 1,000,000 bytes sequentially from SSD: 62 microsecond.
Read 1,000,000 bytes sequentially from disk: 947 microsecond.
Round trip network request in same data centre : 500 microsecond.
Send 2000 bytes over commodity network: 62 nanosecond.

Time Taken for payload to travel over TCP:

Here is the amount of time required to transmit various data payloads on typical cell networks around the world assuming no data loss.

RTT — Round Trip Time — Total time taken for a data packet (bunch of data bytes) to travel from sender to receiver & receiver to sender over the network. In short, it’s called Ping time.

Transfer of 1 byte to 13,000 bytes (roughly 13 KB) data takes 1 round trip or 1 RTT. Rough time taken in USA: 150 millisecond, India: 1200 millisecond, Brazil: 600 millisecond.
13,001 bytes — 39,000 bytes (13 KB to 39 KB) takes 2 RTT. Rough time taken — USA: 300 millisecond, India: 2400 millisecond, Brazil: 1200 millisecond.
39,001 bytes — 91,000 bytes (39 KB to 91KB) takes 3 RTT. Rough time taken-USA: 450 millisecond, India: 3600 millisecond, Brazil: 1800 millisecond.
91,001 bytes — 195,000 bytes (91 KB to 195 KB) takes 4 RTT. Rough time taken — USA: 600 millisecond, India: 4800 millisecond, Brazil: 2400 millisecond.

So more the response size, more bytes, more round trip, more the API latency, less user friendly app. :(

Power of 2

These numbers come in handy when you estimate storage size or cache size for your system. Make use of the “Approximate value” field which corresponds to the same figure represented in terms of power of 10.

Availability Numbers

Every service has a predefined SLA (Service Level Agreement), it’s a contract between the service (or service owner) and the customer. It’s mostly represented in terms of 9’s. More the 9 better. Following are some very important to remember availability numbers:

Detailed Availability Numbers from Wikipedia

Size of Common Database Data Types

The strange thing in the above data is YEAR . It takes only 1 byte . How?

Well, it turns out that MySQL like database systems consider years from 1901 to 2155. Essentially, 2155 — 1901 = 254 -> this values can easily be represented by 1 byte

Instead of storing the entire year values, they store the difference from 1901

Redis QPS and TPS

Redis QPS, TPS depend on couple of factors:

Network Bandwidth: Network bandwidth and latency directly impact Redis performance. Estimate throughput in Gbit/s to compare with theoretical network limits; for example, 100,000 requests per second with 4 KB strings requires 3.2 Gbit/s , suitable for a 10 Gbit/s link but not 1 Gbit/s. In many scenarios, network limits Redis throughput before CPU does. For consolidating high-throughput Redis instances, consider a 10 Gbit/s NIC or multiple 1 Gbit/s NICs with TCP/IP bonding.
CPU configuration: Redis being single threaded ( from the point of view of client operations ) favours fast CPU with large cache and not many cores. Intel CPUs are better than others. If you have multiple CPUs, you should run multiple Redis instances in the same machine to utilize them.
Memory: For small objects ( 10 KB ), speed of RAM and memory bandwidth does not matter much. For objects with size >10 KB, it might become noticable. It’s not much cost effective to buy expensive fast memory modules.
Data Size: What data structures and data size (as you can see above) you use, that matter too. QPS and TPS would be lesser for sorted set than string.
Redis runs faster in physical machines with local disk than a VM.
Use of pipelined commands: “When an ethernet network is used to access Redis, aggregating commands using pipelining is especially efficient when the size of the data is kept under the ethernet packet size (about 1500 bytes). Actually, processing 10 bytes, 100 bytes, or 1000 bytes queries almost result in the same throughput.” In general, pipelining is nothing but batching multiple Redis commands together so that you can save on the network round trip time.
Disk Persistance: Enabling AOF and snapshotting could impact the results. Enabling them makes sense only if you need durability guarantee or need to compare Redis to transactional data stores.
Number of connections: “With high-end configurations, the number of client connections is also an important factor. Being based on epoll/kqueue, the Redis event loop is quite scalable. Redis has already been benchmarked at more than 6000 connections, and was still able to sustain 50000 QPS in these conditions. As a rule of thumb, an instance with 30000 connections can only process half the throughput achievable with 100 connections.”

Being said that, the ball-parked Redis QPS ans TPS figure is going to be around 200,000/sec. With Redis cluser, it would probably even touch 500,000 k /sec or more.

Note that both read QPS and write TPS are pretty much in the same level.

Cloud RDBMS Storage Configurations

Often in real life and system design interview, we need to calculate database index size and storage size. For that, it’s better to use more realistic memory and disk size to calculate the exact number of machines rather than assuming wrong configurations.

RAM and CPU

Following table shows virtual CPU, RAM (in Gigabytes) and max bandwidth for different classes of database available in AWS. Different cloud provider offer different type of instances with a variety of configurations. Some instances are memory optimized, some are compute optimized or both, some latest generation CPU etc.

Nevertheless, the following data might help you to assume realistic CPU and memory configurations. As you can see 256 to 512 GB is safe to assume for RAM size in a design discussion.

More info here.

Disk Space

The following figures are in TB (Terabytes). As you can see, 64 TB is a safe disk space to assume per machine in a design discussion.

More info here.

CDN Cost

This is the cost of Amazon Cloudfront as of June 26, 2021 which charges for data served out to the internet / origin server per GB per month depending on amount of data served. Other CDN provider may charge differently.

This chart will help you to roughly figure out the CDN cost during system design.

This post will be updated as and when new or updated numbers are found. Please let me know if you are aware of new numbers.