Partitioner

Assigns an aggregate to a partition. The hash is part of the storage format: it is fixed across JVMs, processes and versions (64-bit over context.aggregate/tenant/id, never String.hashCode), so every node and every release agrees, and changing it means repartitioning the log.

Slots. An aggregate hashes first to one of SLOTS fixed slots, slot = floorMod(hash, 4096), which never changes; its partition is slot mod P. P must be a power of two that divides SLOTS (1, 2, 4, …, 4096, isValidPartitions): a log, a command topic or a host configured with another count fails at start. Since P divides 4096, floorMod(hash, 4096) mod P = floorMod(hash, P), so the slots assign every aggregate to the partition it had before they existed: logs, checkpoints and Kafka command partitions are unaffected. They are there for the online splits of 10.x, which double P: partition p splits into p and p + P by the next bit of the slot, so an aggregate only ever moves from its partition to that partition's own child, and history stays where it is.

Distribution. A slot is the low 12 bits of the hash, and FNV-1a's low bits depend only on the low bits of each byte (bit k of the hash on bits 0..k of the bytes): the 12 bits of a slot see every bit of every byte, but a partition of a small P sees only the low bits of each character, so keys that differ only in a character's high bits (a and A differ in bit 5) share a partition when P is at most 32. Over keys as ids are made (sequences, UUIDs, snowflakes) the slots and partitions stay uniform; PartitionerTest checks it. A mixer would fix the low bits, but it would change every assignment: a new format, not this one.