I always like to give a concrete example that’s happened to me and does not involve finance :)
National drug codes (NDCs) identify finished drug products in the USA. 50580-600-02, as an example, uniquely identifies a ten-tablet blister pack of paracetamol manufactured by Johnson and Johnson.
Today. But because of the way the format is defined, there are a limited quantity of valid identifiers. As a result, the FDA will periodically expire old NDCs and reassign them. So five years ago, that NDC might’ve referred to another drug entirely. Or, the record you stored yesterday might’ve pointed to the wrong drug because a NDC reassignment happened that the pharmacy processed before you could.
My advice: if you can make your history append-only, do so. So e.g. you correct when someone’s new salary became valid, but you don’t change any of the records about payments owed (and made of course); rather you just add correction records. You can’t recalculate what someone was owed at a historical point in time given the knowledge at the time… but do you really need that information, given that you do have a record of what the system calculated at that time? That you can recalculate what they are actually owed and how large the correction should be is often enough.
I always like to give a concrete example that’s happened to me and does not involve finance :)
National drug codes (NDCs) identify finished drug products in the USA.
50580-600-02, as an example, uniquely identifies a ten-tablet blister pack of paracetamol manufactured by Johnson and Johnson.Today. But because of the way the format is defined, there are a limited quantity of valid identifiers. As a result, the FDA will periodically expire old NDCs and reassign them. So five years ago, that NDC might’ve referred to another drug entirely. Or, the record you stored yesterday might’ve pointed to the wrong drug because a NDC reassignment happened that the pharmacy processed before you could.
I wrote up my own examples based on Martin Fowlers patterns here; https://lukeplant.me.uk/blog/posts/life-on-the-diagonal-adventures-in-2d-time/
I find the bitemporality offered by xtdb quite nice. Now if I’m in SQL land I seek out the comfort of that overhead.
Speaking of xtdb, I wrote a response to this article when it was published:
https://www.juxt.pro/blog/bitemporality-more-than-a-design-pattern
My advice: if you can make your history append-only, do so. So e.g. you correct when someone’s new salary became valid, but you don’t change any of the records about payments owed (and made of course); rather you just add correction records. You can’t recalculate what someone was owed at a historical point in time given the knowledge at the time… but do you really need that information, given that you do have a record of what the system calculated at that time? That you can recalculate what they are actually owed and how large the correction should be is often enough.