☒ If you find yourself in a situation where there are already a bunch of callbacks in the model and you're wanting to clean things up a bit, there are a few approaches you can take. First, start to separate and isolate things. You can do this with namespaced concerns. This will help you get an overview at a glance what you'll be dealing with. Otherwise, code from the model will start to blend in and it will be confusing. Once things are separated, the decisions can be made to leave it the way it is or to start removing the callbacks. Having appropriate test can help expose any breaks in your refactors so I'd say that will be an important part; especially for a large model. Try to identify where the parts are that could ultimately trigger the callback as you'll likely need to touch those areas of code. Overall, I think that the main ones that I would focus on would be the ones that involve other models. Those tend to be the most brittle and the most trouble makers. A callback which only affects the model record itself is usually okay and could be argued that it is "good enough" to be left alone.
☒ I had originally implemented this in an application and ended up disliking it. It was on a table with a potential of several billion records. I ended up ditching this effort as it was cumbersome to work with at times. I haven't looked back since. I ended up going with an unsigned BIGINT which can go up to 18,446,744,073,709,551,615. This was good enough for my purposes. I think that I would revisit this if I had a situation where concurrency was a major concern and duplicate IDs could be possible.
