One customer generates 60% of your event volume. Their partition's consumer cannot keep up and the rest idle. What are your options?

What the interviewer is testing

Whether you can enumerate the options and state what each costs, rather than proposing one fix.

Why the obvious moves fail

Adding consumers does nothing — a partition is consumed by exactly one member of a group, so the hot partition's throughput is capped by one consumer regardless of group size.

Adding partitions does nothing either, because the tenant's key still hashes to one of them. It also remaps every other key, which is disruptive.

The options

Composite key with a bounded suffix. Partition on tenant_id:N where N is a small random or round-robin value, spreading the tenant across several partitions. Cost: per-tenant ordering is lost. Acceptable only if the downstream computation is order-insensitive or re-aggregates afterwards.

Dedicated topic or cluster for the large tenant. Route their events separately, with capacity sized for them. Cost: routing complexity and a per-tenant operational surface. This is what most mature multi-tenant platforms end up doing for their largest customers, and it has the benefit of isolating their incidents too.

Sub-key partitioning. If ordering is only required per entity within the tenant rather than across the whole tenant, partition on tenant_id:entity_id. This preserves the ordering that actually matters and distributes the load naturally. Cost: none, if the ordering requirement is genuinely per entity — which it usually is.

Faster consumer — batching, parallelism within the consumer across independent keys, or optimising the processing. Cost: engineering effort; and it only buys headroom, not scalability.

The recommendation

Examine the ordering requirement first. Teams routinely partition by tenant when the real constraint is per-entity ordering, and correcting that assumption solves the problem with no trade-off. Only if tenant-wide ordering is genuinely required do the other options apply, and then dedicated capacity is usually the cleanest.

What a strong answer adds

Anticipating it in design: model the key distribution with real data before choosing, and expect that any multi-tenant system will eventually have a tenant an order of magnitude larger than the rest.

Common weak answers

Scaling the consumer group. Increasing partition count without analysis.