System Design Primerβš‘

Performance vs scalabilityβš‘

A service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.1

Another way to look at performance vs scalability:

Source(s) and further readingβš‘

Latency vs throughputβš‘

Latency is the time to perform some action or to produce some result.

Throughput is the number of such actions or results per unit of time.

Generally, you should aim for maximal throughput with acceptable latency.

Source(s) and further readingβš‘

Availability vs consistencyβš‘

CAP theoremβš‘


Source: CAP theorem revisited

In a distributed computer system, you can only support two of the following guarantees:

Networks aren't reliable, so you'll need to support partition tolerance. You'll need to make a software tradeoff between consistency and availability.

CP - consistency and partition toleranceβš‘

Waiting for a response from the partitioned node might result in a timeout error. CP is a good choice if your business needs require atomic reads and writes.

AP - availability and partition toleranceβš‘

Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.

AP is a good choice if the business needs allow for eventual consistency or when the system needs to continue working despite external errors.

Source(s) and further readingβš‘


Links: [[System Design]] | [[Web Development]] | Backend Web Architecture 1 | [[010-Development-MOC|Development]]

Source: donnemartin/system-design-primer