What anti-pattern occurs when sharding by a timestamp routes all new writes to the most recent shard?

What anti-pattern occurs when sharding by a timestamp routes all new writes to the most recent shard?

• A. Hot Spot from Time-Based Sharding
• B. Cross-Shard Queries
• C. Range-Based Sharding
• D. Directory-Based Sharding

Answer: (A)

Hot spots occur when time-based sharding routes all new writes to the most recent shard. Since every write lands in the latest shard, that shard bears the bulk of write traffic, becoming a bottleneck that limits throughput and can drive up latency. This creates an unbalanced system where one shard is overloaded while others are underused, complicating capacity planning and maintenance. To understand why this happens: time-based sharding partitions data by time windows, but if the routing logic always targets the newest window, older shards sit mostly idle for writes. The problem is not the shard scheme itself but the lack of distribution inside that scheme. Mitigations include splitting shards earlier and more aggressively, or adding a second distribution method (like hashing within each time window or using a composite key) so writes don’t all funnel into a single shard. The other patterns mentioned don’t describe this exact issue. Cross-shard queries refer to querying across multiple shards, while range-based and directory-based sharding describe how keys map to shards, not the pathological write skew that creates a single hot shard.

Hot spots occur when time-based sharding routes all new writes to the most recent shard. Since every write lands in the latest shard, that shard bears the bulk of write traffic, becoming a bottleneck that limits throughput and can drive up latency. This creates an unbalanced system where one shard is overloaded while others are underused, complicating capacity planning and maintenance.

To understand why this happens: time-based sharding partitions data by time windows, but if the routing logic always targets the newest window, older shards sit mostly idle for writes. The problem is not the shard scheme itself but the lack of distribution inside that scheme. Mitigations include splitting shards earlier and more aggressively, or adding a second distribution method (like hashing within each time window or using a composite key) so writes don’t all funnel into a single shard.

The other patterns mentioned don’t describe this exact issue. Cross-shard queries refer to querying across multiple shards, while range-based and directory-based sharding describe how keys map to shards, not the pathological write skew that creates a single hot shard.