Architecture scenarioHard~12 min

Interview question

How would you choose a partition key for an event stream?

Choose a partition key for an event stream

Explains partition key selection for ordering, load distribution, hot keys, and consumer scalability.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would choose a partition key based on the ordering and processing boundary. If events for the same order must be processed in order, order id is a natural key. If tenant-level ordering matters, tenant id may fit, but large tenants can create hot partitions. The key needs enough cardinality to distribute load while grouping the events that truly need ordered processing.

Full answer below

Practice focus

Partitioning, per-key ordering, hot partitions, consumer scaling, data skew, and operational monitoring.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Partition keys decide both ordering and scalability. A poor key can create hot partitions or lose the only ordering guarantee the system needed.
I would choose a partition key based on the ordering and processing boundary. If events for the same order must be processed in order, order id is a natural key. If tenant-level ordering matters, tenant id may fit, but large tenants can create hot partitions. The key needs enough cardinality to distribute load while grouping the events that truly need ordered processing.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid keys that are either too broad or too random. A constant key creates one hot partition and kills parallelism. A random key distributes load but destroys per-entity ordering. I would look at expected traffic distribution and identify hot customers or resources. Sometimes the design needs sharding within a tenant or a different workflow for extreme keys.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor partition lag, throughput per partition, consumer assignment, hot keys, and rebalancing behavior. Changing a partition key later can be painful because ordering, replay, and storage layout depend on it. I would document the guarantee clearly: events are ordered per key or per partition, not globally. That keeps consumers from assuming stronger ordering than the stream provides.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Choosing tenant id without considering very large tenants.
Using random keys when per-entity ordering matters.
Assuming partitioned streams provide global order.
No monitoring for hot partitions.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot name the ordering boundary.
Ignores data skew.
Has no partition lag metric.
Does not understand consumer scaling impact.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What happens with one huge tenant?
How would you detect a hot partition?
How would replay be affected by partitioning?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Try a variant

Answer a similar question in a different context.

Message Ordering

Architecture scenarioHard~12 min

Interview question

How would you choose a partition key for an event stream?

Choose a partition key for an event stream

Explains partition key selection for ordering, load distribution, hot keys, and consumer scalability.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Partitioning, per-key ordering, hot partitions, consumer scaling, data skew, and operational monitoring.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Partition keys decide both ordering and scalability. A poor key can create hot partitions or lose the only ordering guarantee the system needed.
I would choose a partition key based on the ordering and processing boundary. If events for the same order must be processed in order, order id is a natural key. If tenant-level ordering matters, tenant id may fit, but large tenants can create hot partitions. The key needs enough cardinality to distribute load while grouping the events that truly need ordered processing.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid keys that are either too broad or too random. A constant key creates one hot partition and kills parallelism. A random key distributes load but destroys per-entity ordering. I would look at expected traffic distribution and identify hot customers or resources. Sometimes the design needs sharding within a tenant or a different workflow for extreme keys.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor partition lag, throughput per partition, consumer assignment, hot keys, and rebalancing behavior. Changing a partition key later can be painful because ordering, replay, and storage layout depend on it. I would document the guarantee clearly: events are ordered per key or per partition, not globally. That keeps consumers from assuming stronger ordering than the stream provides.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Choosing tenant id without considering very large tenants.
Using random keys when per-entity ordering matters.
Assuming partitioned streams provide global order.
No monitoring for hot partitions.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot name the ordering boundary.
Ignores data skew.
Has no partition lag metric.
Does not understand consumer scaling impact.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What happens with one huge tenant?
How would you detect a hot partition?
How would replay be affected by partitioning?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Try a variant

Answer a similar question in a different context.

Message Ordering

How would you choose a partition key for an event stream?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant

How would you choose a partition key for an event stream?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant