Hey James,
I'm going to jump in on your question,
*Adam's conversation starter method:* Idempotency is an ugly maintenance
issue which must be maintained (and protected) for end users IMO.
*Paul's suggested method:* No Idempotency impact . . . or least none that
I'm aware of. (check me for sanity. There is a big difference in stating
what "I think" and what "I know")
Again, I'm parroting a solution from very similar problem . . . my actual
understanding is not as deep as Adam's will be. But my confidence comes
from multiple failures on this issue until we "got it".
There are exactly 703 ways to do this "thing"!!! (Ok, maybe an
exaggeration, but got your attention!)
We just need *ONE method which implements and scales perfectly and once
complete, has virtually no maintenance cost. *
When you compare the other 702 ways it COULD be done, please look at total
effort to implement, THEN effort to maintain and compare the factors side
by side.
Here is a suggested minimum list of "compare factors" with my guess taken
from similar experiences. A few factors are subjective, but most can be
quantified factually.
Feel free to add a factor if its major impact I missed something obvious.
*Please* think through these for yourself and compare these method and test
any other approach that might be a candidate.
*Factor uuid method
snowflake method*
Uniqueness 100%
Good, but not 100%
Clock skew Still works
Breaks
Machine ID dependency None
Critical, brittle element in cloud scaling.
Implementation effort Simple
Complex (in a closed system not a big deal, but in
Open Source, 50% fails)
Operational risk Low
High
Cognitive load on implementer Low
High
Idempotency handling Simple. Uses default.
Segregated keys, storage and potection required
Index behavior Great
Great
Multi-tenacy Support Yes
Yes, with additional effort and complexity.
Cost of ownership Very Low
High - multiple complexities must be set correctly,
then maintained. If hardware changes occur, then "do over".
Forward compatibility Supported in
Java/Postgres Legacy tied to hardware
--
Regards,
Paul
