Your geospatial data is partitioned by city. One city generates 40% of all traffic. What are your options?

What the interviewer is testing

Whether you can enumerate skew remedies and state what each costs.

Why the obvious moves fail

Adding capacity does nothing, because a partition is served by specific nodes and the partition does not split.

More partitions does nothing either, because the city still hashes to one of them — and it remaps every other key, which is disruptive.

The options

Sub-partition the hot city by a finer spatial cell. Instead of city, partition by city:cell_id at a resolution that divides the busy city into many partitions. This is usually the best answer for geospatial data, because the access pattern is already spatial — queries ask about an area, not about a city — so the finer key preserves locality while distributing load.

Cost: queries spanning a wide area now touch more partitions.

Dedicated capacity for the hot city. Route it to its own cluster, sized for it. Preserves everything, adds routing complexity and a per-city operational surface.

Cost: an operational special case, though it also isolates that city's incidents.

Composite key with a bounded random suffix. Distributes reliably and destroys locality and per-key ordering, which for spatial queries is usually disqualifying.

Tiered partitioning by size. Large cities get their own partitions; the long tail shares. Common in mature multi-tenant systems.

The recommendation

Sub-partition spatially, because it aligns the partition key with the query pattern rather than fighting it. Reserve dedicated capacity for the small number of cities that remain outliers even after sub-partitioning.

What a strong answer adds

The design-time lesson: model the key distribution with real data before choosing, and assume skew. Every real-world distribution is skewed — cities, tenants, channels, products — and a key chosen from the logical model rather than from the measured distribution produces a hot partition eventually.

And the observation that skew is not static: today's hot city is not next year's, so the scheme needs to accommodate rebalancing without a migration project.

Common weak answers

Scaling the cluster. Caching, which helps read-heavy skew and not write skew.