madno

Nice pattern indeed.

This articles explores when it is not the case to apply it (for example when eventual consistency would be a big problem): https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-...

I guess at some level of load (for scalability reasons) one might need to decouple writing into the append only event log from updating the tables for fast reads, so the one transaction approach won't work, hence the eventual consistency between written data and read data.

Schema maintenance is also a non-trivial task as described in the article: keeping backward compatibility for various event versions, upcasting, lazy upcasting. Hitting a good granularity level for events is important, too big or too small, both are a problem.

For the operational team without intimate app knowledge it is also harder to do ad-hoc work.

LOL, appreciate the link :D

For total ordering are you using an instant (with say seconds granularity) or an additional monotone id to distinguish between changes for the same day?

Sounds like SAP :)

Haven't heard specifically of the terminology "three schema approach", but the idea fits with other notions I've heard about: https://www.martinfowler.com/bliki/BoundedContext.html and Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...

Your approach sounds sensible! Do you have some blog posts, pointers which further explains the approach and factors to consider?