`erlang:unique_integer(Opts)` is not cluster unique! It isn't even unique if a node restarts, but it is unique over a system instances lifetime.

It's speed depends on what options you set. If you request `erlang:unique_integer([monotonic])` then you have to lock because you need to synchronize multiple cores (lock here means atomic updates on a 64bit integer, so "lock"). Without monotonic, each scheduler can have it's own ID and then you return (SchedID << 64) + Supply or something equivalent.

If you need unique integers over node reboots, then you need to store something else on persistent storage which tells you what generation count your system is currently at. Thus, you can discriminate older integers from newer integers. If you don't need monotonic, you can just do:

    unique_id() ->
        ID = erlang:unique_integer(),
        Generation = read_generation(),
        Node = node(),
        {ID, Generation, Node}.

and use the triple as your unique ID. Default ordering on tuples, which is lexicographic, then easily makes sure you can compare such ID's and you also obtain a total order on the ID's.

When you say "it is unique over a system instances lifetime"? Do you mean an erlang node running on 1 machine?

So every node has its own generation. Every generation starts at 1, and every time it restarts, you read the current generation and increment it?

The `unique_integer` must be strictly monotonic when given the monotonic option right? When there's no monotonic, that just means the subsequent id can be higher or lower, but not the same.

Given the triple {ID, Generation, Node}, is the Node id unique & different across restarts or the same?