Distributed Databases

Distributed Databases

A distributed database is a collection of data that is stored across multiple physical locations—often on different servers or even in different geographic regions—but behaves as a single logical database to users and applications.

A distributed database is a collection of multiple, logically interrelated databases that are physically spread across different locations (such as multiple servers, data centers, or geographic regions) but connected via a network. To the end-user or application, the system operates seamlessly and appears as a single, cohesive database.

Unlike traditional centralized databases that run on a single machine, distributed databases utilize multiple "nodes" to share the workload, which dramatically increases resilience, availability, and scalability

🔑 Core Concept

Instead of keeping all data in one central server, distributed databases split and replicate data across nodes.
Each node can:

• Store a portion of the data (partitioning)
• Maintain copies of data (replication)
• Process queries locally or collaboratively with other nodes

This design improves availability, scalability, and fault tolerance, which ties directly to the CAP theorem you’re reading in your current tab.

⚙️ Architecture Types

Type	Description	Example
Homogeneous	All nodes run the same DBMS and schema	PostgreSQL clusters
Heterogeneous	Different DBMSs or schemas across nodes	Polyglot persistence (MongoDB + SQL Server)
Federated	Independent databases linked via middleware	Enterprise data integration systems

🧩 Key Components

• Data Fragmentation: Dividing data into logical pieces (horizontal or vertical).
• Replication: Copying data across nodes for reliability.
• Transparency: Users see one unified database, not multiple servers.
• Concurrency Control: Ensures consistent transactions across nodes.
• Commit Protocols: Two-phase or three-phase commit ensures atomicity.

✅ Advantages

• High Availability: If one node fails, others can serve requests.
• Scalability: Add more nodes to handle growing workloads.
• Performance: Local queries reduce latency.
• Fault Tolerance: Redundant data prevents loss.

⚠️ Disadvantages

• Complexity: Synchronization and consistency management are hard.
• Network Dependency: Performance relies on stable connectivity.
• Data Conflicts: Concurrent updates can cause inconsistencies.
• Maintenance Overhead: Requires sophisticated monitoring and coordination.

🏆 Real-World Examples

• Google Spanner → Globally distributed, strongly consistent (ACID).
• Amazon DynamoDB → Highly available, eventually consistent (BASE).
• Cassandra → Peer-to-peer architecture, tunable consistency.
• CockroachDB → SQL interface with distributed resilience.

📌 Relation to CAP Theorem

Distributed databases must balance:

• Consistency (C) → Same data everywhere.
• Availability (A) → Always responsive.
• Partition Tolerance (P) → Operates even if nodes can’t communicate.

No system can fully achieve all three simultaneously—each chooses trade-offs based on its design goals.

💡 Key Takeaway

Distributed databases are the backbone of modern cloud systems. They enable global scalability and resilience but require careful design to manage trade-offs between consistency, availability, and latency—as described by CAP and PACELC theorems.