Sharding is an architectural pattern for horizontal partitioning of data across multiple database nodes. It improves scalability and availability by distributing load, but requires routing logic, consistency considerations and additional operational effort. Design decisions include shard keys, rebalancing strategies, cross-shard transactions and monitoring.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Sharding distributes the records of a logical database across separate partitions so storage capacity and load can scale horizontally.
Sharding emerged as a response to data volumes and access loads that a single database server could no longer handle economically. Distribution follows a chosen shard key.
Each shard owns only part of the data. A request containing the shard key can be routed selectively; cross-shard queries must contact multiple shards. The key affects load distribution, hotspots, rebalancing, and the complexity of transactions and backups. Sharding is therefore a scaling and operations decision, not an automatic improvement for every database.
A logical data set is split across multiple physical shards.
A key determines where a record resides and where requests are routed.
Distribution can increase capacity and throughput but complicates cross-shard queries, rebalancing, and operations.
Sharding helps classify large data platforms and their scaling limits. Access distribution, key selection, consistency requirements, and added operational effort are decisive.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.