Partitioning assigns work; state gives that work a history

A partitioned source divides a log into independently progressing sequences. Kafka preserves its defined ordering within a partition, not a universal order across every partition in a topic. An offset identifies a position within its partition; offset 100 in one partition is not necessarily earlier than offset 90 in another. A source reader's recoverable position therefore needs a vector of partition identities and positions. Record identity is a separate application choice, especially when producers can submit duplicate business events at different log offsets.

Downstream repartitioning can route the same business key from several source partitions to one keyed operator. This makes per-key history available at the responsible instance, but it does not invent a meaningful global order among unrelated events. If order matters within a key, define which upstream guarantees or sequence fields establish it. A timestamp alone can tie or arrive late. More parallel readers can increase available work while a hot key still concentrates state and processing on one owner. Diagnose skew before assuming an equal partition count means balanced CPU or memory usage.

In Flink 2.1's state model, keyed state is associated with a key after keyed partitioning, so an update can refer to the current key's history. Operator state belongs to a parallel operator instance and uses declared redistribution behavior when parallelism changes. A source's assigned partition positions are a useful operator-state example; a user's running sum is a useful keyed-state example. Arbitrary mutable fields in application code do not automatically acquire the recovery and redistribution guarantees of managed state. Use the documented state interface and preserve its identity through upgrades.

State size depends on distinct active keys, retained history, serializer representation, indexes, and overhead. A bounded input batch may eventually end, while an unbounded stream needs an explicit reason old state can be removed. A count per permanent customer grows with customer cardinality; a raw event buffer grows with retained events. An incremental aggregate can store less than a full history only when its algebra and later corrections permit it. A smaller state representation must preserve the required answer, not merely make a checkpoint or dashboard look lighter.

Restoring an old aggregate while restarting sources after newer offsets loses contributions; restoring a newer aggregate while replaying earlier records can count contributions twice. A coordinated checkpoint connects source positions with operator state and, where required, channel state at a consistent cut. That guarantee concerns recovery of the managed computation. Outputs to an external service need their own compatible commit or replay contract. Keep logical state ownership, live storage, durable snapshots, and external visibility as separate parts of the system diagram.

The modular lab illustrates uneven coverage in a deliberately fictional routing rule. Reset, explicitly set BOTH modulus m=8 and additive step a=2, predict that only four residues are visited, then Play or Step. Reset and re-set BOTH m=8 and a=3; predict all eight residues before repetition. Playback selects n=floor(2t), not real partition arrivals. Edits retain t and recompute the orbit. Flink does not assign keys with this additive toy; use it only to show why a routing rule's coverage must be checked rather than inferred from the number of available buckets.