db-partitioning-sharding (M16)

Scaling topology is Performance & Scale (axis performance); feeds relational Escala w12 (shared with M17/M2/M9) and the Shard-key / Partición&hot categories in NoSQL profiles. The two failure directions are symmetric: scaling too late (a monster table that should be partitioned) and scaling too early (sharding a 5 GB database that a single node handles trivially).

What it checks

1. Partitioning fit — large append-only / time-series tables (events, logs, metrics) that would benefit from Postgres declarative range/list partitioning (cheap pruning, fast retention drops) but are a single heap.
2. Hot partition / skewed key — a partition or shard key with low cardinality or temporal skew (e.g. partitioning by tenant_id where one tenant is 90% of traffic, or all writes hitting "today's" partition). On wide-column stores an unbounded/hot partition on an event table is severity:5 (perf) with live write-rate evidence — otherwise directional.
3. Premature sharding — application-level sharding / multiple shards introduced with no size or throughput justification, adding cross-shard-query and rebalancing cost for no benefit.