ORIGINAL TECHNICAL PRACTICE
Choose a partition key with skew in mind
A multi-tenant event store must scale while keeping customer histories queryable. How would you choose its partitioning strategy?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
A good partition key balances distribution with access patterns. Partitioning only by tenant may preserve locality but create a hot partition when one large tenant dominates traffic.
Work through it
- Measure tenant-size and request skew, write patterns, retention and common query ranges. Estimate the largest tenant rather than just the average.
- Consider tenant plus time bucket or a bounded shard suffix, and define how readers locate the required partitions. Keep indexes and uniqueness requirements in the design.
- Test resharding, late events and a hot-tenant burst. Establish routing metadata, migration steps and reconciliation before changing the partition function.
Tradeoffs to discuss
- Additional sharding spreads load while increasing read fan-out and coordination. Larger time buckets improve locality but can concentrate active writes.
Common pitfalls
- A hash does not automatically eliminate hotspots when the input key itself is highly skewed. A partition change without a versioned routing plan can make data appear missing.