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
