@Tom Daly <td...@mifos.org> I agree on the approach proposed by Adam because it is very useful for
High-volume inserts (while doing withdrawals, deposits or repayments) Distributed architectures (K8s clusters and multi region data centers) Time-sensitive data (like the interaction with real time payment systems or blockchains) TL;DR Some reasoning behind the Snowflake and how it compares to others ID generators: https://malikatique.medium.com/high-performance-snowflake-id-generator-for-java-0081e902bb5d https://www.alibabacloud.com/blog/using-snowflake-style-ids-in-apsaradb-rds-for-postgresql_602448 https://chientrm.medium.com/snowflake-id-generation-for-serverless-runtime-e3f354319e39 Regards Victor El jue, 4 sept 2025 a las 11:16, James Dailey (<jdai...@apache.org>) escribió: > 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 >> >
