Systems Design

Notes on distributed systems, database internals, and scalable architecture.

CAP Theorem

In a distributed system, you can only guarantee two of three:

Consistency — Every read gets the most recent write
Availability — Every request gets a response
Partition Tolerance — System works despite network partitions

Practical Implications

System	Choice	Example
CP	Consistency + Partition Tolerance	ZooKeeper, etcd
AP	Availability + Partition Tolerance	Cassandra, DynamoDB
CA	Consistency + Availability	Single-node databases

Consensus Algorithms

Raft

Raft breaks consensus into three sub-problems:

Leader Election — One node is elected leader
Log Replication — Leader replicates log entries to followers
Safety — Only nodes with up-to-date logs can become leader


Client → Leader → Followers (majority ack) → Committed → Applied

Key Metrics

Latency: Bounded by network round-trip + disk write
Throughput: Limited by leader’s I/O capacity
Availability: Tolerates (n-1)/2 failures in cluster of n

Database Internals

B-Tree vs LSM-Tree


B-Tree (Read-optimized):
├── Balanced tree structure
├── In-place updates
├── Good for read-heavy workloads
└── Used by: PostgreSQL, MySQL

LSM-Tree (Write-optimized):
├── Append-only writes to memtable
├── Periodic compaction to disk
├── Good for write-heavy workloads
└── Used by: RocksDB, Cassandra

Choosing the right data structure depends on your workload. Profile before optimizing.

References

Designing Data-Intensive Applications — Martin Kleppmann
The Raft Consensus Algorithm — Ongaro & Ousterhout
Google Spanner: TrueTime and External Consistency — Corbett et al.