The first time someone told me about EDA was when I told them I had problems optimizing a certain SQL query, to which their answer was whether I have considered using event sourcing or storming.
* If you write down what happened ("events"), and don't throw away said events, then you can always compare the current state of the system to how you think it should be (according to the events).
> I had problems optimizing a certain SQL query
* If you don't mutate your events, you are allowed to share them. Perhaps the DB you were working with had an unsuitable structure, making it hard to write fast SQL. No worries! Create a second service/DB with a structure designed for fast querying. Slurp the events which you did not throw away into your new database, and enjoy fast queries (without needing to break or cause regressions in the first service/db).
Unless what happens in the system is different now and old events don't make sense anymore...
This, by the way, is the fundamental principle of accounting. When you hear “reconciliation” this is what they’re doing - comparing some data reflecting real events against a log of intended events. For example, a nonprofit might reconcile their bank account (actual $ amounts) against GL files generated from their CRM (expected $ amounts.)