Distrubuted Storage,Computation,Clocks (Global Clock/Vector Clock), Read Replicas

 

🌍 Global Clock in Distributed Systems — Ramesh Style

This is an important Distributed Systems / Microservices interview concept. The easiest way to understand it is:

In a single machine, time is easy. In distributed systems, every machine has its own clock, so there is no perfectly reliable shared clock.

---

1. Single Machine — Simple

Imagine one Java application:

Java Application
       |
       ↓
   CPU / OS
       |
       ↓
   System Clock
       |
       ↓
   07:10:30

Every event uses the same clock:

Event A → 07:10:30
Event B → 07:10:31
Event C → 07:10:32

So we can easily say:

A happened before B
B happened before C

---

2. Distributed System — Problem Starts 🚨

Now imagine three microservices:

             Network
        ┌───────┼───────┐
        ↓       ↓       ↓
   Service A Service B Service C
      🕐        🕐        🕐
    10:00:01  10:00:03  09:59:59

Each machine has its own physical clock.

Suppose:

Machine A clock = 10:00:01
Machine B clock = 10:00:03

A sends a message to B:

A: "I created Order-101"
       |
       | network
       ↓
B: "I received Order-101"

You might expect:

A event = 10:00:01
B event = 10:00:02

But B's clock might say:

B event = 09:59:59

Now timestamps appear to say:

B event happened BEFORE A event

even though B received A's message after A sent it.

That's the problem.

---

3. Why don't we simply synchronize clocks?

We can synchronize machines using systems such as NTP/PTP.

But perfect synchronization is impossible in a distributed environment.

There are several reasons.

Network latency

A
 |
 |-------- 20 ms -------->
 |
 B

Sometimes:

A → B = 20 ms
B → A = 50 ms

Clock drift

Hardware clocks don't run at exactly the same rate.

Machine A
10:00:00
10:00:01
10:00:02

Machine B
10:00:00
10:00:01.001
10:00:02.002

The difference gradually increases.

Network partition

Machine A     X     Machine B
             NETWORK
             FAILURE

They can't synchronize at all.

---

4. The Important Question

Distributed systems don't always need to know:

"Exactly what time did this event happen?"

Often they only need to know:

"Which event happened before which other event?"

That's where Logical Clocks come in.

---

5. Physical Clock vs Logical Clock

Think:

                TIME
                  |
          ┌───────┴────────┐
          ↓                ↓
    Physical Clock    Logical Clock
          |                |
     Real-world time   Event ordering
          |                |
      NTP / PTP       Lamport / Vector

Physical clock

Example:

10:30:45.123

Used for:

• logging

• monitoring

• expiry

• scheduling

• timestamps

Logical clock

Example:

Event A = 1
Event B = 2
Event C = 3

It doesn't necessarily represent actual time.

It represents:

Ordering of events.

---

6. Lamport Logical Clock ⭐

This is the first logical clock you should learn.

Suppose:

Service A                     Service B

Event A1
  |
  | message
  ↓
                            Event B1
                              |
                            Event B2

Lamport clock assigns numbers.

Service A

A1 = 1
  |
  | message
  ↓
Service B

B1 = 2
B2 = 3

So we know:

A1 → B1 → B2

Meaning:

A1 happened-before B1
B1 happened-before B2

---

7. Lamport Clock Rules

Remember these three rules.

Rule 1 — Local event

Increment clock:

L = L + 1

Example:

L = 0

Event A
 ↓
L = 1

Event B
 ↓
L = 2

---

Rule 2 — Sending a message

Increment before sending:

L = L + 1

Then send timestamp.

A
L = 5

send(message, timestamp=6)

---

Rule 3 — Receiving a message

Suppose receiver has:

Local clock = 3

Message contains:

Sender timestamp = 6

Receiver calculates:

max(3, 6) + 1

So:

max(3,6) + 1
= 7

Receiver clock becomes:

7

---

8. Complete Lamport Text Flow Diagram

Service A                         Service B

Clock = 0                         Clock = 0

Event A1
Clock = 1

Event A2
Clock = 2

      SEND message
      timestamp = 3
          |
          |------------------------>
                                   Receive
                                   max(0,3)+1
                                   Clock = 4

                                   Event B2
                                   Clock = 5

                                   Event B3
                                   Clock = 6

Therefore:

A1 → A2 → Send → Receive → B2 → B3

The logical clock gives us the ordering.

---

9. What is "Happens-Before"?

This is another very important interview term.

We write:

A → B

and say:

A happens-before B

There are three basic cases.

Case 1 — Same process

A
↓
B

Therefore:

A → B

---

Case 2 — Message passing

A
|
| message
↓
B

Therefore:

A → B

---

Case 3 — Transitivity

If:

A → B
B → C

then:

A → C

---

🔥 10. Important Limitation of Lamport Clock

Lamport clocks tell us:

L(A) < L(B)

But this does not always mean:

A caused B

Two events may be completely independent.

Example:

Service A                 Service B

A1                         B1
 |                          |
 |                          |
(no communication)

Maybe:

A1 = 5
B1 = 8

We cannot conclude:

A1 happened-before B1

just because:

5 < 8

This is where Vector Clocks become useful.

---

11. Vector Clock — Next Level

Instead of one number:

Lamport:

A = 5

Vector clock keeps knowledge about multiple processes.

Suppose:

3 services:

A
B
C

A vector may be:

[A, B, C]

Example:

[2, 1, 0]

Meaning roughly:

A knows 2 events from A
A knows 1 event from B
A knows 0 events from C

---

12. Vector Clock Text Flow

Service A             Service B

[A:1 B:0]             [A:0 B:0]

Event A1
[A:1 B:0]

     SEND
       |
       | [1,0]
       ↓

                      Receive
                      [2,1]

                      Event B2
                      [2,2]

Now the system has more information about causal relationships.

---

13. Why Vector Clocks Matter

Suppose:

A writes X
B writes Y

and there was no communication:

A: Write X

B: Write Y

Vector clocks can detect:

X and Y are concurrent

Meaning:

Neither write causally happened before the other.

That's useful in distributed databases and conflict detection.

---

14. Global Clock vs Logical Clock

This is the key comparison for your notes.

Global/Physical Clock	Logical Clock
Represents real-world time	Represents event ordering
Can have clock drift	Doesn't depend on synchronized physical clocks
Network latency affects synchronization	Message ordering is captured logically
NTP/PTP can synchronize approximately	Lamport/Vector clocks provide logical ordering
10:30:45	Event = 7
Useful for timestamps	Useful for causality

---

15. Where does this appear in Microservices?

This is where your Java Architect background connects directly.

Imagine:

             Order Service
                   |
              Order Created
                   |
                   ↓
             Kafka Message
                   |
          ┌────────┴────────┐
          ↓                 ↓
   Payment Service     Inventory Service
          |                 |
          ↓                 ↓
     Payment Done      Stock Reserved

Now ask:

Which event happened first?

Physical timestamps might be unreliable because machines have different clocks.

But message flow gives us causal ordering:

Order Created
      ↓
Payment Started
      ↓
Payment Completed

and:

Order Created
      ↓
Inventory Reserved

Logical clocks help reason about this ordering.

---

16. Distributed Database Example

Suppose two nodes:

Node A                    Node B

User balance = 100        User balance = 100

Network partition:

Node A       X       Node B

Both receive updates:

A → +50
B → -20

Now:

A = 150
B = 80

When they reconnect, the system needs to understand:

Which update happened before which?

Logical timestamps/vector clocks can help identify:

A update
B update

and whether they're:

causally related

or

concurrent

This connects directly to the CAP theorem you just studied.

---

🧠 Ramesh Class Notes

Global Clock

Distributed System
       ↓
Multiple Machines
       ↓
Multiple Physical Clocks
       ↓
Clock Drift + Network Latency
       ↓
No Perfect Global Time
       ↓
Need Event Ordering
       ↓
Logical Clocks
       ↓
┌──────────────┬──────────────┐
↓              ↓
Lamport       Vector
Clock         Clock
↓              ↓
Ordering      Causality +
              Concurrency

---

⭐ Interview Definitions

Global Clock

A hypothetical synchronized time reference shared by all machines. In real distributed systems, perfect global synchronization is difficult because of clock drift, network latency and failures.

Logical Clock

A mechanism that assigns logical timestamps to events so that distributed systems can determine event ordering without relying on perfectly synchronized physical clocks.

Lamport Clock

A logical clock that provides a total ordering consistent with the happens-before relationship.

Vector Clock

A logical clock that tracks causal relationships among multiple processes and can identify concurrent events.

Happens-Before

A relation used to establish causal ordering between distributed events.

---

🔥 Final Mental Model

Don't think:

Distributed System
       ↓
"What exact time did this happen?"

Think:

Distributed System
       ↓
"Did A happen before B?"
       ↓
       YES
       ↓
Causality / ordering
       ↓
Logical Clock
       ↓
┌─────────────┬──────────────┐
│             │
Lamport       Vector
│             │
Order         Causality +
              Concurrency

One-line memory trick

Physical clock tells you "when"; logical clock tells you "before/after"; vector clock tells you "who knew what and whether events were concurrent."

----

Read replication is a technique used in distributed systems to enhance data availability and scalability by duplicating data across multiple nodes. Here’s a breakdown of the concept:

Purpose: The primary goal of read replication is to allow read operations to be distributed over multiple replicas of the data, 

which reduces the load on the primary data source and eliminates bottlenecks during read-heavy workloads.

Architecture: In a typical read replication setup, one server (the primary or master) handles write operations, while one or more secondary (or replica) servers handle read requests. This separation allows for the optimization of read and write workloads.

Consistency: To maintain consistency, the replicas are updated in accordance with the changes made to the primary server. 

There are different consistency models to consider:

Synchronous Replication: Updates are confirmed on all replicas before acknowledging the write operation, ensuring strong consistency.

Asynchronous Replication: Updates are propagated to replicas after acknowledgment of the write operation, which might introduce eventual consistency but improves performance.

Benefits: The main advantages of read replication include:

Increased Read Performance: By balancing the load across multiple replicas, systems can handle more read requests simultaneously.

Fault Tolerance: If the primary server goes down, applications can still read from replicas, increasing system resilience.

Scalability: Adding more replicas can easily scale the read capacity without drastically affecting the write performance.

Use Cases: Read replication is commonly used in web applications, content delivery networks, and systems requiring high availability and low latency access to data.

Thus, read replication is a vital strategy in distributed systems that promotes performance and reliability while managing the complexities of data consistency across multiple nodes. If you have any questions or need further clarification on any specific part, feel free to ask! 

----

Now more write compare to reads, then need to change strategy going for sharding.

Here are structured class notes on sharding for your study:

Sharding

Definition: Sharding is a database architecture pattern that involves partitioning data across multiple databases (shards) to distribute the load 

and improve performance. Each shard contains a portion of the data.

Purpose: The primary goal of sharding is to:

Enhance scalability by allowing a database to grow horizontally.

Distribute the load to improve read and write performance.

Isolate failures to individual shards, improving fault tolerance.

How It Works:

Data Partitioning: Data is divided into smaller, more manageable pieces called shards based on a specific key. This key could be customer ID, geographic location, or any other attribute relevant to the application.

Sharding Strategy: Common strategies for sharding include:

Hash-Based Sharding: A hash function is used to determine which shard an entry belongs to.

Range-Based Sharding: Data is partitioned based on ranges of values. For example, IDs from 1 to 1000 might go to shard 1, while IDs from 1001 to 2000 go to shard 2.

Benefits:

Increased Throughput: By balancing the load across shards, systems can handle more simultaneous queries and transactions.

Improved Latency: Read and write operations can be executed in parallel across multiple shards, reducing wait times.

Flexibility: Shards can be added or removed dynamically according to traffic demands, providing operational flexibility.

Challenges:

Complexity: Implementing sharding can add complexity to the system architecture, including the need for robust routing and querying mechanisms.

Data Distribution: Maintaining uniform data distribution across shards is crucial for performance and can be challenging to achieve.

Use Cases: Sharding is commonly used in applications with large datasets, such as social media platforms, e-commerce websites, and online gaming, where high scalability and performance are essential.

Feel free to reach out if you have questions or need more details on specific aspects of sharding!