Lesson 3 — Architectures, Cloud Responsibility, ACID / BASE / CAP
Centralized, distributed, federated
- Centralized: data in one system/place. Can simplify control and suit restricted data, but creates a concentrated access dependency.
- Distributed: multiple systems/nodes. Can scale and increase availability, but adds coordination, failure, replication, and consistency complexity.
- Federated: autonomous component databases retain local control while being mapped/presented through a combined logical view; source data need not be copied into a new persistent store.
- Non-federated distributed: multiple components, but they are centrally controlled rather than autonomous.
Within federation: - Loosely coupled: component databases retain more independent schema knowledge; users may need source/location awareness. - Tightly coupled: an integrated federated schema is constructed and published.
Federation ≠ replication. Federation unifies access; replication deliberately maintains copies.
Virtualization and cloud responsibility
Virtualization decouples logical services from physical location/configuration. It does not remove security, retention, recovery, capacity, or governance obligations.
Three Chapter 6 approaches:
- Virtual machine image: owner runs/administers database software on a VM.
- Database-as-a-Service (DaaS): provider installs and maintains the database service; consumer pays/uses according to service model.
- Managed database hosting: provider hosts/manages the owner's database, but the database is not offered in the same generic service sense as DaaS.
Ask who patches, backs up, monitors, secures, restores, and owns retention/performance requirements.
ACID, BASE, CAP
ACID — transaction reliability
- Atomicity: all-or-nothing transaction.
- Consistency: move from one valid state to another.
- Isolation: concurrent transactions do not interfere incorrectly.
- Durability: committed result persists.
BASE — availability/eventual-consistency posture
Basically Available · Soft state · Eventual consistency. Temporary stale/inconsistent views may be tolerated while replicas converge.
CAP — distributed partition trade-off
Consistency · Availability · Partition tolerance. CAP addresses what a distributed system does under partition/failure conditions. It is not another transaction guarantee like ACID and it is unrelated to relationship cardinality.
Scenario clues
- debit/credit must commit together → Atomicity / ACID
- replica may be stale temporarily but converges → BASE-style eventual consistency
- during a network partition, balance consistency vs availability → CAP
Avoid the absolute simplification “SQL = ACID, NoSQL = BASE.” Chapter 6 describes common design postures; products vary.
Source: pp. 171–176.