3 ms·
> Usually it is hard with distributed computations to say what happened before and what happened after. Using those IDs you always know the order of certain eve
by throwaway41597 11y ago
> Usually it is hard with distributed computations to say what happened before and what happened after. Using those IDs you always know the order of certain events.
Which "certain events"? The typical case I can think of wouldn't work:
- at time t0, event e0 occurs on client c0, an id is requested
- at time t1 > t0, event e1 occurs on client c1, an id is requested
- id1 = 62 is generated and returned to client c1
- id0 = 63 is generated after because of network latency
The IDs say that event e1 reached the ID generation servers before event e0, but I don't see when this would be useful, e0 still happened before, it may even be causally older than e1.
Am I missing something?
- random42 11y agoMy understanding is only server side events are considered. So for ordering perspective, if due to network latencies e0 reaches the server later than e1, id0 > id1 is correct behaviour.
- throwaway41597 11y agoBy "client" I meant client of the ID generation servers, may they be web servers that run DB clients, or cellphones. When someone uses a distributed ID generation cluster, they presumably want large throughput, like millions of IDs per second, and latency will likely be a problem.