Adam Thanks for raising this. Is it a big enough change to warrant a FSIP (Fineract significant improvement proposal) decision VOTE?
I’d also like to know if this design change may create other downstream challenges- I could imagine that the sequential numbering is considered a “feature” and utilized by outside components. Anyone in the community with a view on this? I was thinking though whether you could make this a deployment flag, and therefore optional, but I think that ends up creating some difficult patterns and therefore lots of additional maintenance overhead. Do you agree? Lastly and just wondering, how does this proposed change interact, or not, with the Idempotency code? James Sent from Gmail Mobile On Thu, Sep 4, 2025 at 4:37 AM Paul <pchristi...@gmail.com> wrote: > Hi Adam, > I'm not super technical, but have faced similar issues in the past and > will try to regurgitate what we discovered as a "better way" which might be > useful. > > First, let me share using the Machine ID in the sequence ends up being an > ugly pain in the ass point and was a near catastrophic issue for us . . . > so while your solution would be an improvement, it creates new risks which > are just as onerous. That was on metal servers. With cloud services, > scaling and churn would seem to multiply the risk? While I'm sure there are > ways around each challenge, again, each "way around" complicates the > solution and worse, increases time, cost and cognitive load. > > I going to suggest (PLEASE double check my sanity) 128-bit IDs using > time-ordered UUIDs v7. This provides global uniqueness with the only > negative being a slight increase in index size (16 vs 8 bit). It should > avoid several "what ifs" on clock issues (jumps and fall backs) and risk of > using Machin ID, you will discover a LOT of extra effort is required to > make those work. THEN after ALL that, will find that uniqueness is NOT > certain. I found this out the hard way. In short, we tried what sounded > like your method and failed to enjoy a truly scalable solution. In fact, we > made 3 major efforts to get it to "play nice" and failed. > > This simplified method provides immediate ops benefit, is a low risk > implementation. (Lead Developer, suggested it was zero risk, but I don't > beleive in such a thing) We were working with Postgres, Java app, NOT > Fineract, but assuming its generally applicable. > > Assumptions: > 1) You're not trying to remove or replace primary keys and will keep them > for internal use > 2) Postgres handles indexing of uuid auto-magically; as long as the column > is marked unique > 3) Use uuid as the public ID in APIs > > If you think this is helpful or a better option, feel free to quiz me. > > Regards > Paul >
