Distributed Systems for Backend Engineers · Distributed Systems in Practice
Real-World Architectures: DynamoDB, Spanner and Kafka
How production systems apply these ideas.
DynamoDB (inspired by Dynamo): partitioned by key, replicated across AZs with Paxos-based leaders per partition, offering eventually consistent or strongly consistent reads, transactions within a region, and global tables with multi-region last-writer-wins. Spanner: globally distributed SQL with Paxos groups, TrueTime and external consistency. Kafka: partitioned replicated logs, ISR replication, KRaft (Raft-based) metadata, exactly-once within Kafka. Each is a set of explicit trade-offs.
Production systems compared
| Aspect | DynamoDB | Spanner | Kafka |
|---|---|---|---|
| Data model | Key-value / document | Relational (SQL) | Partitioned log |
| Replication | Multi-AZ, Paxos per partition | Paxos groups, multi-region | Leader + ISR followers |
| Consistency | Eventual or strong reads; LWW across global tables | External consistency (strict serializable) | Per-partition order; acks=all durability |
| Cross-region writes | Global tables: LWW by default; multi-Region strong consistency mode available | Yes, consistent (higher latency) | MirrorMaker / cluster linking |
| Trade-off | Scale + simplicity vs query flexibility | Consistency vs latency/cost | Throughput vs per-message features |
Common pitfalls
- Using DynamoDB global tables without considering LWW conflicts.
- Expecting Spanner latency like a single-node DB for cross-region writes.
- Treating Kafka as a database.
Key points
- Every system is explicit trade-offs
- Know the consistency guarantees you depend on
- Read the papers/docs
Further reading: USENIX ATC '22: Amazon DynamoDB
Practice questions
How do DynamoDB global tables resolve concurrent writes in different regions?
Answer
In the default (multi-Region eventual consistency) mode, with last-writer-wins reconciliation, so concurrent updates to the same item can overwrite each other; a newer multi-Region strong consistency mode avoids this at the cost of write latency.
What makes Spanner's external consistency possible?
Answer
TrueTime provides bounded clock uncertainty, and Spanner waits out that uncertainty when committing, so commit timestamps respect real-time order.
Open in the app to mark lessons complete, take notes and track your progress.