[solipsism]

Maybe to someone who's already familiar with other, longer descriptions of the problem. I don't know what problem this is solving and that description doesn't do much for me.

Can someone either explain, or point to a fuller explanation, of the purported problem?

[Terr_]

There are some overlapping architectural ideas here, I find they build upwards like this:

CQRS: You have one "write" data-model which is specialized for transactions and applying business rules... and other "read" models that take care of things like dashboards, detailed information pages, searching, generating reports, etc.

Chronological events: A really handy way to propagate changes from the write-model into the various read-models.

Event-sourcing: This is "dogfooding" your own events. Instead of just emitting optional messages to other systems, you make them essential, and use them as the authoritative record for your own system's state. This adds certain kinds of flexibility that you may (or may not) need.

[dj-wonk]

If one describes CQRS as being mostly about a write (e.g. master data) + read (e.g. derived data) combination, how far could one get with a relational system with views and triggers?

[Terr_]

Pretty far, I imagine, especially with things like materialized views... I'm just biased against putting more logic into the DB than strictly necessary, given the difficulty of versioning that logic and how the DB is often the bottleneck among multiple webservers.

[jamii]

This is an excellent explanation - http://blog.confluent.io/2015/01/29/making-sense-of-stream-p...

[reubano]

Very nice!Here's a good follow up on the inner workings of onyx. https://github.com/MichaelDrogalis/onyx/blob/0.5.x/doc/user-...

[CmdrDats]

Thanks jamii, that's an excellent read - I forgot to add it to the Further Reading section! Will do that now :)