This is a huge argument for shared data libraries where you can enforce the rules of your data in a single place. Not always possible (business-wise) to implement but it is nearly always worth pushing for.
That's called a database. That entire post could be summarized as "look, some dumbass didn't put a foreign key constraint on the currency column".
Nice. I'm going to spoil the surprise and just tell you: in enterprise environments there are tens or hundreds of databases talking to one another through all kinds of different layers of orchestration, and the One Person In Charge of database #24 is never the One Person In Charge of databas #81.
What you're talking about is a "Single Source of Truth", and for most large companies it's a pipe dream. Very large technology companies try to -- and somewhat do -- solve some permutations of this problem (see: IBM Initiate), but enterprise environments are by and large held together with bubble gum and duct tape.
Don't even get me started on data sets that have to join living in different timezones when timestamp is critical. There are rules for this sort of thing, but chances are nobody who's on the project knows what they are.
What is with all the random nonsense comments here lately? I am not suggesting a single source of truth, the person I replied to was. I simply pointed out that if you are trying to have such a source, the database is where to put it, not a shared library that all the codebases maybe use sometimes.
I am genuinely sad that such a statement would ever be uttered. "Even when"? Why would you choose to use a database that isn't reliable?
>Consistency check should be replicated in your application layer, atleast for mission critical data.
Maybe if there were some way to do that, but there isn't. It doesn't get replicated, it gets re-implemented, which is quite different. And it results in application code in app X that says data is bad while the DB says it is ok, and then application Y also says it is ok and inserts it fine, and then app X pukes getting it back out later, etc. Leave the DB in charge of the rules and when it gives you an error, you can go ahead and relay that error to the user (in a nicer format one would assume).