2 ms·
> Tricks such as indexes, partitioned tables, etc can be employed, but those tricks have nothing to do with event-sourcing and are independent of it. You might
by mrkeen 3y ago
> Tricks such as indexes, partitioned tables, etc can be employed, but those tricks have nothing to do with event-sourcing and are independent of it.
You might want to use different tricks in different situations. Different situations means different services, and different tricks means different storage/query technologies.
So how do you get your data into three systems - and more crucially - keep them in sync? Webhooks? Triggers? Some bidirectional sync magic app that claims to beat CAP?
Just use event-sourcing (append-only, disallow modification) and the multiple systems will stay in sync as long as they know how to process one more message.
- Nextgrid 3y agoAgreed with your points but this article seems to present event-sourcing as a replacement for your database(s) and even makes claims about saving storage space, thus at least hinting at not using databases anymore.
- mrkeen 3y agoIt's a replacement for your source-of-truth, not your database(s). Although you're right about the article not explicitly mentioning slurping the events back into a DB. I suspect the reason is that there are plenty of articles which explain how to event-source from greenfield, but this is the first one I've seen which focuses on existing brownfield relational data - see the title. > makes claims about saving storage space I don't think that was the right reading about saving storage space: > We’ve been trying to optimise the storage size; we’ve made some sins of overriding and losing our precious business data I think it's his strawman RDBMS developer who optimised for saving storage space, and lost business data as a result. The suggested approach is: > We can optimise for information quality instead of its size.