Distributed Systems Flashcard

Go Variable Scope (Q1.1)

Shared by all goroutines (threads). It is the same variable in memory, not a new copy.

Race Condition (Q2.1)

When multiple threads access a shared variable at the same time, and at least one writes. The result is unpredictable.

sync.Mutex (Q2.1)

A lock in Go. You use mu.Lock() before and mu.Unlock() after accessing a shared variable to prevent data corruption.

Deadlock (Q1.2)

A state where two or more processes are stuck forever, each waiting for a resource the other one holds.

Starvation

A process is ready to run but is indefinitely ignored or passed over (e.g., a low-priority job) while other processes get resources.

Livelock

Processes are active and busy (changing state), but make no actual progress. Like two people stuck in a hallway, constantly dodging each other.

TCP (Q1.3)

A reliable network protocol. It guarantees all data arrives in the correct order. (Like a phone call).

UDP (Q2.4)

An unreliable network protocol. It's fast, but packets ("datagrams") can be lost or arrive out of order. (Like a postcard).

IP (Q1.3)

The Network Layer protocol. Its job is addressing and routing packets from one computer to another.

Transport Layer (Q1.3)

The layer that manages communication for specific processes (using ports). TCP and UDP live here.

Microservices

An architecture style that builds one big application as a set of many small, independent services.

RPC (Remote Procedure Call)

A way to call a function on a remote server as if it were a local function in your own code.

RPC Limitation (Q1.4)

It's a "leaky abstraction." It hides the network, but the network is not reliable. This causes partial failures (e.g., the call works, but the answer is lost). 16

gRPC

A fast, modern RPC. Uses HTTP/2 and Protocol Buffers (binary format). Good for internal microservice communication.

REST

An API style based on resources. Uses HTTP/1.1 (GET, POST) and JSON (text format). Good for public/web APIs.

API Gateway

A single "front door" for all clients. It receives requests and routes them to the correct internal microservice.

Service Discovery

A "phone book" for microservices. It helps services find the network address (IP:port) of other services they need to call.

Circuit Breaker

A safety pattern. If a remote service keeps failing, the "breaker" trips (opens) and fails requests immediately to let the service recover.

Saga Pattern

Manages distributed transactions. If a step fails, it runs compensating transactions (rollbacks) to undo the previous steps.

Clock Drift (Q1.5)

The problem where physical computer clocks are imperfect and slowly run at different speeds, "drifting" apart from each other. 22

Clock Discontinuity (Q1.5)

When a clock suddenly jumps forward or backward in time, usually because it's being synced by NTP (Network Time Protocol). 27

Lamport Timestamps (Q1.6)

A logical clock (a counter). Guarantees: If A happened-before B, then $L(A) < L(B)$. 30

Lamport Weakness (Q1.6)

If $L(A) < L(B)$, it does not mean A happened-before B. They could be concurrent (unrelated). 30

Vector Clocks

An advanced logical clock. Guarantees: A happened-before B IF AND ONLY IF $V(A) < V(B)$. Can detect concurrent events. 33

Centralized Mutex (Q1.7)

A distributed lock controlled by one coordinator server. Its main weakness is being a Single Point of Failure (SPOF). 41

Ricart & Agrawala (Q2.2)

A decentralized lock algorithm. To enter, a node must get a REPLY from all other nodes. 47

R&A Weakness (Q2.2)

Not fault-tolerant. If any node crashes or a REPLY message is lost, the requesting node will starve (wait forever). 48

Byzantine Fault (Q1.8)

A faulty node that is malicious. It can lie and send different messages to different nodes to cause confusion. 54

Byzantine Tolerance (Q1.8)

To tolerate $f$ malicious nodes, you must have a total of $N \ge 3f + 1$ nodes. (Less than 1/3 can be traitors). 54

RAFT (Q1.9)

A leader-based consensus algorithm. One node is elected leader and manages log replication. 60

RAFT Network Partition (Q1.10)

Only the partition with a majority of nodes can elect a new leader and commit new entries. The minority partition is "offline" and can't make progress. 69

Linearizability (Q2.3)

Strong consistency for a single object. Guarantees every operation appears to happen instantly at one point in time. Respects real-time order.

Serializability

Strong consistency for transactions (groups of operations). Guarantees the result is the same as running them one-by-one in some serial order.

Strong Consistency

A model where all reads are guaranteed to see the most recent write. Data is instantly the same everywhere.

Eventual Consistency

A weak model. Guarantees that if no new updates occur, all nodes will eventually converge to the same value. Allows temporary "stale" (old) reads.