Is Splitting Data Across Machines Distributed? Understand Sharding vs Distributed Systems

Central Warehouse

Using an e‑commerce warehouse example, the article starts with a single central warehouse that eventually reaches capacity limits as the number of products grows.

The manager then splits the inventory by category into five separate warehouses (3C, apparel, fresh, home, books), each handling its own stock independently. This physical separation represents data sharding.

Problems of Pure Sharding

When a customer orders items from multiple categories, the service must contact each warehouse separately; the warehouses have no knowledge of each other's inventory, mirroring how sharded databases require custom code to aggregate results across shards.

Need a Scheduling Center

A scheduling layer is added so each warehouse registers the categories it manages. Incoming orders are first sent to this scheduler, which routes the request to the appropriate warehouse. This mirrors sharding middleware such as Vitess (VTGate) or MongoDB Sharded Cluster, where a routing layer maintains shard rules, rewrites queries, merges results, and may coordinate cross‑shard transactions, while the underlying database instances remain independent.

The coordination layer becomes a single point of failure; if it crashes, the whole system is affected, and it must also orchestrate multi‑warehouse orders.

Real Distributed Systems

True distribution goes beyond a scheduler: each node directly perceives others, synchronizes inventory and capacity, and can automatically reallocate stock or route orders when a node fails. Nodes communicate via protocols and achieve consensus using Raft or Paxos, enabling automatic routing, replication, failover, and load balancing. Examples include TiDB, CockroachDB, and YugabyteDB.

Back to Databases

In database terms, a sharded system remains a collection of independent instances with an added routing layer; it is easier to adopt on existing databases but introduces complexity for cross‑shard transactions, global consistency, and fault tolerance, and the router can become a bottleneck.

A distributed database integrates node collaboration from the start: data is still partitioned, but nodes continuously replicate state, handle failover, and perform data migration as part of the core engine.

Selection Criteria

Choosing between sharding and a distributed database depends on two factors: (1) workload characteristics—if most queries hit a single shard and cross‑shard transactions are rare, sharding may suffice; if frequent cross‑shard queries, multi‑node transactions, or automatic scaling and failover are needed, a distributed database is preferable.

(2) Team capability—sharding requires the team to design shard keys, implement routing, and manage data migration, whereas a distributed database offloads much of that work to the engine but still demands operational expertise.

Summary

Sharding solves "how to split data and where to place it"; distributed systems solve "how multiple nodes cooperate after the split". A system can implement only sharding, only distribution, or both, but merely spreading data across machines does not make it a distributed system.