Understanding Distributed Systems Concepts

1. Understanding Distributed Computing Challenges

ChallengeDescriptionMitigation
Partial failureSome nodes fail, others continueTimeouts, retries, idempotency
Network unreliabilityPackets lost/delayed/reorderedTCP, retries, ack protocols
ConcurrencyMultiple nodes act simultaneouslyLocks, consensus, CRDTs
No global clockCannot order events globallyLogical clocks, NTP+TrueTime
HeterogeneityMixed HW/OS/lang versionsStandard protocols, schemas
SecurityUntrusted networkmTLS, signed messages

2. Understanding the Fallacies of Distributed Computing

#FallacyReality
1Network is reliablePackets lost, partitions occur
2Latency is zeroLight-speed lower bound; cross-region 100ms+
3Bandwidth is infiniteBottleneck under load
4Network is secureAlways assume hostile
5Topology doesn't changeAuto-scaling, deploys, failures
6One administratorMulti-team, multi-cloud
7Transport cost is zeroEgress costs $$, serialization CPU
8Network is homogeneousMixed protocols, devices, versions

3. Understanding Network Partitions and Failures

Failure TypeSymptomDetection
Crash failureNode stops respondingHeartbeat timeout
Omission failureSome messages droppedAcks + retries
Network partitionSubset cannot reach othersQuorum loss detection
Byzantine failureArbitrary/malicious behaviorBFT consensus
Gray failureSlow but not failedp99 latency, hedged requests

4. Understanding Clock Synchronization

ClockMechanismAccuracy
NTPPublic time servers~10–100ms
PTPHW timestamps in DC<1µs
GPS/AtomicDirect hw referencens range
TrueTime (Spanner)GPS+atomic+uncertainty bound<7ms uncertainty
Warning: Never rely on wall clocks for ordering across nodes — clock skew, drift, and leap seconds make it unsafe.

5. Understanding Vector Clocks and Lamport Timestamps

TypeCapturesLimitation
Lamport timestampSingle counter, total orderCannot detect concurrent events
Vector clockPer-node counters; partial orderO(N) size, GC complex
Version vectorReplica versioning for conflictsUsed in Dynamo, Riak
Hybrid Logical ClockPhysical + logical bitsBounded skew, used in CockroachDB

Example: Vector clock causality

Node A: [A:1]  → send msg → Node B receives
Node B: merges = [A:1, B:1]  → send to C
Node C: [A:1, B:1, C:1]
Concurrent: [A:2, B:0] vs [A:0, B:2] (neither dominates)

6. Understanding Distributed Transaction Challenges

ChallengeCauseSolution
Atomicity across nodesPartial commits2PC, 3PC, Saga
Coordinator failureBlocks participantsTimeouts, 3PC, Paxos commit
PerformanceMany round tripsBatch, optimistic concurrency
Cross-DB transactionsXA limited supportSagas, outbox pattern

7. Understanding Two-Phase Commit (2PC)

2PC Protocol

  1. Prepare: Coordinator sends PREPARE; participants vote YES (write to log) or NO
  2. Commit: If all YES → COMMIT; any NO → ABORT; participants apply and ACK
PropertyBehavior
AtomicityAll commit or all abort
BlockingIf coordinator dies after PREPARE, participants block
Latency2 round trips + log fsyncs
Used inXA transactions, distributed RDBMS

8. Understanding Three-Phase Commit (3PC)

PhaseAction
CanCommitCoordinator asks participants if they can commit
PreCommitIf all yes, coordinator says "prepare to commit"
DoCommitFinal commit; participants ACK
Note: 3PC is non-blocking with synchronous network but unsafe under network partitions. Modern systems prefer Paxos/Raft commit.

9. Understanding Distributed Snapshots

AlgorithmPurposeUse Case
Chandy-LamportConsistent global snapshot via markersDeadlock detection, checkpointing
Asynchronous Barrier SnapshotSnapshot in stream pipelineApache Flink checkpointing
Copy-on-writePoint-in-time view of stateZFS, etcd snapshots

10. Understanding Byzantine Fault Tolerance

AlgorithmToleratesUse Case
PBFT(N-1)/3 malicious nodesHyperledger, permissioned chains
Tendermint1/3 byzantineCosmos SDK
PoW (Nakamoto)<50% hash powerBitcoin
PoS variants<1/3 stake byzantineEthereum, Solana
Note: BFT requires 3f+1 nodes to tolerate f byzantine failures. Used where actors may be malicious (blockchains, multi-org systems). Not needed in trusted DCs.