[gbrits]

The proposed architecture really works well for me. I've used it for a couple of projects now.

To throw around some terms for those interested in reading up/background: - The separation of writes (through log) from reads (through any of the consumers) is sometimes called: CQRS (command query responsibility separation) - having a centralized log as the defining store for updates/ change events is sometimes called: eventsourcing - as mentioned in article: elastic search as a consumer of the log, which only gets updates through the log, is an example of an Eager Read Derivation.

All defined on site of Fowler.

Glad to see this getting more attention. Asked about usage for Kafka as an eventsource here some time ago. Includes insightful answer of Kafka author. http://stackoverflow.com/questions/17708489/using-kafka-as-a...

[Terr_]

> having a centralized log as the defining store for updates/ change events is sometimes called: eventsourcing

To clarify slightly: Event Sourcing isn't just emitting events for others, it means that your system is re-reading its own log to derive current state from past-events.

For performance reasons you try to avoid this with stuff like periodic "snapshots", but the capability of has to be there.

[rjbwork]

This is exactly what I thought of as soon as I read it.

"Hey, this is just CQRS by a different name!"

It works well, but it is very hard to get large teams of people to all do things this way. All it takes is for one guy to do a direct write, and his reviewer to miss it, and boom, inconsistency.