Shared-Nothing Architecture 

In a shared-nothing system, nodes don’t share disks or memory.
Instead, each node manages its own portion of the data and contributes equally to query execution and replication.

That independence makes CrateDB:

• Highly fault-tolerant: if one node fails, others continue to serve queries.
• Massively scalable: add nodes to increase both compute and storage capacity.
• Operationally simple: no central coordinator or external storage dependencies.

Every node can perform every operation (reads, writes, and query processing) ensuring that performance scales naturally with your data and user demand.

Advantage	Impact
No single point of failure	Continuous uptime and data availability
Linear scalability	Add nodes without reconfiguring the cluster
Workload isolation	Each node operates independently, preventing contention
Automatic rebalancing	Data redistributes evenly as nodes join or leave
Simplicity	Uniform configuration across all nodes

CrateDB builds on the shared-nothing foundation to deliver real-time analytics and search across massive datasets:

• Automatic replication: Data is copied across independent nodes for redundancy.
• Distributed execution: Queries run where the data lives, minimizing network traffic.
• Self-healing clusters: If a node fails or re-joins, CrateDB automatically rebalances data.
• Rolling upgrades: Updates and maintenance happen without service disruption.

Together, these features make CrateDB an always-on distributed database capable of handling real-time workloads at global scale.

CrateDB’s cluster state management is the coordination layer that keeps every node in sync.
It ensures that all nodes share a consistent, up-to-date view of the cluster (its configuration, topology, and data distribution), so the system can operate reliably at scale.

Each node maintains a versioned copy of the current cluster state.
However, only one node (the master node) is authorized to make state changes at runtime.
At any point in time, there can be only one active master, elected by a quorum of master-eligible nodes.
Once a master is elected, the cluster becomes fully operational and ready to handle queries.

When the master node updates the cluster state, it publishes the new version to all other nodes and waits for acknowledgments before proceeding with the next update.
This approach guarantees strong consistency and prevents conflicting changes across the cluster.

The cluster state includes all metadata required for coordination and fault-tolerant operation, such as:

• Global cluster configuration and settings
• Discovered nodes and their health status
• Table schemas and mappings
• Locations and status of primary and replica shards

Together, these mechanisms ensure that CrateDB operates as a cohesive, self-aware system, one that remains consistent, resilient, and ready to rebalance or recover automatically whenever the cluster topology changes.