Take a quick refresher on the building blocks of modern systems, each component of which is a completely scalable application.

Deep Dive into System Design Interview

In this module, we’ll learn about the building blocks of modern systems, each component of which is a completely scalable application itself. These building blocks are the foundation for designing scalable applications. Each building block serves a unique purpose and has its own importance in scalable applications.

Basic Building Blocks for Modern System Design

Optional Revision: Time in a Distributed System

Optional revision: Time in a Distributed System

### Physical clocks

There are often two types of physical clocks available in a computer: the time-of-day clock and monotonic counters.



#### The time-of-day clock:
* This usually has lower resolution in comparison to monotonic counters.
* Network Time Protocol (NTP) can move the clock forward or backward, so it’s not always monotonic.
* It may or may not incorporate leap seconds.

#### Monotonic counters:
* Monotonic counters usually have higher resolution than time-of-day clocks.
* Monotonic counters should be used for the duration between two events rather than for the time.
* These aren’t meaningful across different nodes. For instance, even on the same server with multiple processors, there can be a different counter per processor. The application needs to be careful when using counters from different processors.
* The NTP might adjust it without violating monotonicity.
* The NTP can only speed up or slow down the counter rate of change by up to 0.05%.


### Reasons for clock drift:
Physical clocks drift over time due to many reasons:

* Temperature differences
* The equipment’s age
* Manufacturing defects
* Virtualized clocks


For instance, a server with a clock drift of 200 parts per million implies a six millisecond drift if synced every 30 seconds, or a 17-second drift if re-synced every 24 hours.

A study showed that on the public internet, an NTP couldn’t achieve clock accuracy better than 35 ms, and it can spike to 1 second during network congestion. Otherwise, NTPs use multiple time servers and discard outliers.

### The trade-off: Complexity and cost vs. clock accuracy

It’s possible to keep clock drift consistently small using GPS and atomic clocks, careful deployment, and monitoring. However, such a system comes with an added dollar cost and increased system complexity.


### Logical clocks:
* Lamport clocks provide us with happened-before relationships. If event A happens before event B, then the clock value of A will be less than the clock value of B. There’s a subtle point: given any two clock values from any two servers, we can’t compare them to infer the happened-before relationship, because those two events may be concurrent (i.e., not causally related).
* We can use vector clocks to infer the happened-before relationships using the clock values. For this, we’ll need a counter per participating entity in the vector.
* We should note that happened-before might not mean that two events were causally related. It might be the case that one event happened before the other. Usually, we need application-level context on top of the happened-before mechanism to infer real causality.

Design a distributed sequencer capable of generating unique IDs while preserving event causality. Compare physical clock solutions like Twitter Snowflake and Google TrueTime with logical clocks. Evaluate the trade-offs between consistency, scalability, and complexity in System Design.

Unique IDs with Causality

Causality

Use UNIX time stamps