skip to content

What is the difference between DefaultPartitioner and UniformStickyPartitioner, and when would you choose one over the other?

level: middleimportance: should knowfreq 48%

answer

  1. Default: hash keyed + sticky null
  2. UniformSticky: sticky for ALL records, ignores key
  3. UniformSticky => no key ordering
  4. compaction key but no ordering need => UniformSticky
  5. KIP-794 deprecated both; leave partitioner.class unset

basics

~10 s

Both use sticky batching for null keys. DefaultPartitioner hashes non-null keys with murmur2 to preserve per-key ordering; UniformStickyPartitioner ignores the key entirely and sticks for every record, so it never gives key-based ordering.

solid answer

~40 s

Since Kafka 2.4, `DefaultPartitioner` does two things: for **non-null keys** it hashes with murmur2 (`hash % numPartitions`) so a key always maps to the same partition (per-key ordering), and for **null keys** it uses the sticky strategy from KIP-480. `UniformStickyPartitioner` applies the sticky strategy to **all** records, *including keyed ones* — it ignores the key for partitioning, so you get even, batch-friendly distribution but **no key-based ordering**. Choose `DefaultPartitioner` (the default) when keys carry ordering/co-location meaning. Choose `UniformStickyPartitioner` only when you set keys for some other reason (e.g. log compaction tombstones) but explicitly do not want them to drive partitioning, prioritizing uniform throughput. Note both were deprecated by KIP-794 (Kafka 3.3) in favor of the built-in load-aware partitioner enabled by leaving `partitioner.class` unset.

go deeper

for a junior

Know DefaultPartitioner is the normal one and that it keeps same-key records together.

for a middle

Explain that UniformStickyPartitioner ignores the key (no ordering) while DefaultPartitioner hashes keyed records.

for a senior

Identify the niche use (compaction keys without ordering needs) and cite KIP-794's deprecation.

for a principal

Decide partitioner policy across services, weighing ordering guarantees vs throughput and migration to the load-aware default.

## Two partitioner classes, one shared trick Kafka ships several `Partitioner` implementations. The two most often confused are `DefaultPartitioner` and `UniformStickyPartitioner`. Both implement the **sticky batching** idea from KIP-480 (Kafka 2.4): for records they treat as 'keyless', they stick to one partition until its batch fills, then move on — yielding fuller batches and lower latency. The difference is **how they treat the key**. ### DefaultPartitioner (the default) - **Non-null key:** `partition = Utils.toPositive(murmur2(serializedKey)) % numPartitions`. Deterministic, so the same key always co-locates on one partition → **per-key ordering** is preserved. - **Null key:** sticky strategy (fill a batch on one partition, then pick a new one). This is what you want almost always: keys mean something (a user id, an account, an aggregate root) and you rely on all of a key's records landing together and staying ordered. ### UniformStickyPartitioner - **Every record, keyed or not:** sticky strategy. The key is **ignored** for partition selection. - Result: uniform, batch-efficient distribution but **no key-based ordering** — two records with the same key may land on different partitions. ## When to choose which - **DefaultPartitioner:** the normal case — you have keys and you need ordering/co-location. - **UniformStickyPartitioner:** rare. You attach keys for a reason unrelated to partitioning (commonly **log compaction**, where the key identifies the record to retain/tombstone) but you want maximum throughput and even spread, accepting that key-ordering is *not* needed. Picking it when you actually need ordering is a classic bug. ## The modern caveat (KIP-794) Kafka 3.3 found the original sticky partitioner could send disproportionately to *slow* partitions. KIP-794 introduced a **strictly uniform, partition-load-aware** built-in partitioner and **deprecated both `DefaultPartitioner` and `UniformStickyPartitioner`**. The recommended setup now is to leave `partitioner.class` unset (null) and tune `partitioner.adaptive.partitioning.enable` and `partitioner.availability.timeout.ms`. So in new code you typically do not set either class explicitly. ## Custom alternative If neither fits — say you need a custom skew-aware or geography-aware scheme — you implement the `Partitioner` interface and set `partitioner.class` to your class.

  • If you set keys for log compaction but use UniformStickyPartitioner, what do you lose?
    Per-key ordering and co-location. The key still works as the compaction identity, but records with the same key may scatter across partitions, so you cannot rely on ordering or on a single partition holding a key's full history.
  • What does KIP-794 recommend instead of setting these classes?
    Leave partitioner.class unset so the built-in load-aware partitioner runs, and tune partitioner.adaptive.partitioning.enable and partitioner.availability.timeout.ms. Both DefaultPartitioner and UniformStickyPartitioner are deprecated.

saying these in an interview costs you the question

  • Saying UniformStickyPartitioner preserves per-key ordering — it ignores the key.
  • Thinking DefaultPartitioner round-robins keyed records (it hashes them).
  • Recommending UniformStickyPartitioner as a general default.
  • Not knowing both are deprecated by KIP-794 in current Kafka.

context

resolving links…