Shared-Nothing Architecture

In a shared-nothing system each node owns its own CPU, memory and storage, and nodes communicate only by passing messages. No shared disk, no shared memory, no global lock manager.

This is the architecture of Cassandra, ClickHouse, Elasticsearch, CockroachDB, MongoDB sharded clusters and effectively every system that scales past a single machine.

Why it wins

The alternative — shared-disk — means every node contends for the same storage and needs a distributed lock manager to coordinate access to shared pages. That coordination becomes the bottleneck, and it grows worse with node count.

Shared-nothing removes the contention by removing the sharing. Adding a node adds CPU, memory, storage and bandwidth in one step. Throughput scales close to linearly for workloads that partition cleanly.

What it demands of your data model

The scalability is conditional on one thing: operations must be answerable from a single partition.

• A query with the partition key goes to one node and scales perfectly.
• A query without it becomes a scatter-gather across every node. It works, but its latency is bounded by the slowest node, and its cost grows with cluster size.
• A join across partitions requires moving data between nodes, which some engines refuse to do and others do expensively.

This is why wide-column data modelling starts from queries rather than entities — see Query-First Design.

Where coordination reappears

Shared-nothing does not eliminate coordination; it makes it explicit and, ideally, rare:

• Cluster membership. Nodes must agree on who is in the cluster. Gossip (Cassandra) or a consensus service (ClickHouse Keeper, ZooKeeper, etcd) handles this.
• Data placement. Something must decide which node owns which key range, and update that mapping when nodes join or leave.
• Cross-partition transactions. Available in distributed SQL engines via two-phase commit over consensus groups; expensive by construction. See Distributed Transactions.
• Rebalancing. Adding a node moves data. During the move, the cluster does its normal work plus streaming, which is why capacity should be added before saturation, not during it.

The tail latency problem

In a scatter-gather query, the response time is the maximum of all participating nodes, not the average. With 20 nodes and a p99 of 100 ms per node, a query touching all of them will frequently be slower than 100 ms — the slow tail is hit far more often than intuition suggests.

Node count and failure probability

With more nodes, the probability that some node is degraded at any moment approaches one. A shared-nothing cluster must therefore treat partial failure as normal operating condition, not as an exception: replication so a lost node loses no data, request routing that avoids unhealthy nodes, and repair mechanisms that reconcile what diverged while a node was away.