Help us improve
Share bugs, ideas, or general feedback.
From system-design
Design partitioning and sharding strategies for data at scale. Use when single database hits throughput or storage limits.
npx claudepluginhub sethdford/claude-skills --plugin architect-system-designHow this skill is triggered — by the user, by Claude, or both
Slash command
/system-design:data-partitioningThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design partitioning strategies (sharding, bucketing) to distribute data across multiple databases or nodes, enabling horizontal scaling.
Implements horizontal sharding for PostgreSQL, MySQL, MongoDB including shard key selection, data distribution analysis, query routing, and rebalancing.
Implements range, list, hash, and composite partitioning for PostgreSQL and MySQL tables to optimize query performance and manage large datasets.
Implements PostgreSQL table partitioning by range, list, or hash for large tables (>100GB/100M rows), time-series, multi-tenant data to enable pruning for faster queries and easy maintenance like detaching partitions.
Share bugs, ideas, or general feedback.
Design partitioning strategies (sharding, bucketing) to distribute data across multiple databases or nodes, enabling horizontal scaling.
You are designing data partitioning for large-scale systems. The user faces single database bottlenecks (throughput or storage). Read their data volume, access patterns, and consistency requirements.
Based on designing data-intensive applications and partition strategies from Dynamo/Cassandra:
Choose Partition Key: What key distributes evenly? UserID is obvious for user-centric apps. For IoT, might be (SensorType, RegionID). Avoid keys that hotspot (Country or Status).
Select Partitioning Scheme:
Plan Rebalancing: How do you add capacity? Manual assignment or automatic? How long to rebalance? Require zero-downtime.
Handle Hot Partitions: If UserID=1 gets 1000x traffic, split further (UserID=1-A, UserID=1-B). Or use cache in front.
Define Consistency Model: Within partition, can be strongly consistent. Across partitions, typically eventual consistency. Define what queries require multi-partition reads.