Distributed Databases
Replication, CAP without the slogans, quorums, consensus, leader election, and what a partition really costs you.
A primary streams its changes to replicas that serve reads; asynchronous replication is fast and lagging, synchronous is consistent and slow, and the "I saved it and see the old value" bug is replication lag meeting a naive read route.
Partitioning splits one table across pieces of one database; sharding splits data across separate database nodes — and everything that crosses a shard boundary (joins, transactions, uniqueness, aggregates) becomes the application’s problem.
CAP is not "pick two" — it is a choice you make only during a network partition, between refusing writes to stay consistent and accepting them to stay available; the rest of the time you are trading latency for consistency.