In the event sourcing communities sometimes I hear anti-messaging statements that messaging increases complexity and messaging increases coupling so you should avoid it. I find this strange because when I look at a lot of these event sourcing implementations I can identify several messaging patterns. They are already doing messaging.
An event store is a queue and your aggregates and projections are subscribers of streams. Message queues sometimes call this a topic but there are many varying names for the same thing.
It’s important to remember not to get so hung up on the names of things and to identify the patterns.
Some event store middleware is messaging middleware
Both store messages in-order. Both allow subscribing to a topic (event stores call this a stream id).
Some event stores are even adding various messaging protocol support.
Certainly both have many more features that differentiate from each other and these are only 2 implementations of many but there are common underlining patterns between them.
My opinion is many event sourced systems I’m seeing are message-oriented publish/subscribe systems so these anti-messaging statements conflict.
- Responsible benchmarking
- Understanding hardware still matters in the cloud
- The “network partitions are rare” fallacy
- Messaging and event sourcing
- Further reducing memory allocations and use of string functions in Haywire
- HTTP response caching in Haywire
- Atomic sector writes and misdirected writes
- How memory mapped files, filesystems and cloud storage works
- Hello haywire
- Active Anti-Entropy
- Lightning Memory-Mapped Database
- Write amplification
- Amortizing de-duplication at read time instead of write time
- LevelDB was designed for mobile devices
- AMQP and wire format interopability
- Convergent Replicated Data Types
- Configuration is bad but what about operational flexibility?
- An alternative to Paxos, the RAFT consensus algorithm
- Version tolerance and accidental operation complexity
- Hardware configurations can introduce tight coupling and increase failure foot print
- November 2013
- October 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- January 2013
- October 2012
- September 2012
- August 2012
- May 2012
- April 2012
- February 2012
- January 2012
- December 2011
- September 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010