Thanks.
These are mostly my ideas (not that there are any truly new ideas), but they are more-or-less the result of trying to write idempotent services. That is, making sure the same request always returns the same response (modulo incremented sequences). Analogizing data issues to memory management is very useful to software developers that haven't been beat up by data availability and consistency issues in the past.
It's also useful to study functional programming concepts, especially data immutability and data structures that work within that limitation, to identify possible design patterns for organizing things that themselves don't change.
For more inspiration, learn about the plumbing of git if you haven't already. The fact that commits never change buys git all sorts of things.
How do I model this in a database? I treat (table, sequence_id) pairs like I would memory addresses (or git objects). And I try to design append-only tables as much as possible. No UPDATE queries. Only INSERT (malloc) and DELETE (free). There are a lot of nice benefits here, including the ability to shard based on the age of data, being able to aggressively cache partial results and recalculate only when things change, etc.
To that end, most data is best modeled as a time series if data consistency is an issue (and it is if you need to scale). There are exceptions for axiomatically true things, like mathematical calculations, but for the most part things like "how many users like sandwiches" change depending on when you ask them. So the right question is "how many users like sandwiches as of 11:32:23 today?". Or maybe "how many users liked sandwiches when you ran calculation job 432342?" Then you can collate timestamps or sequence IDs to see if some data is stale, if unused data can be cleaned up, etc.