Distributed ID generators often look simple: combine a timestamp, a counter, and a machine ID. NoNoncense uses that idea for fast counter, sortable, and encrypted nonces. It is a wonderfully fast design, right up until two running nodes receive the same machine ID.
The hard part is not incrementing a counter. It is deciding who may use each machine ID, especially when pods are replaced, nodes autoscale, deployments overlap, and network partitions happen. Two locally correct counters with the same machine ID can produce globally duplicate values.
NoNoncense 1.x left that decision to application startup: derive an ID, initialize the nonce factory, and make the topology safe yourself. That is perfectly reasonable for a fixed fleet. Version 2.0 brings the decision into the supervision tree and gives different deployments a suitable way to establish exclusivity.
Where exclusivity comes from
The strategy is not an afterthought; it expresses what makes an ID unique in a particular deployment:
