Event stores are often misunderstood as messaging tools, but they're better conceptualized as key-value databases where the key is a stream identifier and the value is an ordered list of events. This mental model resolves many common questions: event stores offer the same transactional guarantees as other databases, stream length concerns mirror document size concerns in MongoDB, sharing an event store between microservices is as problematic as sharing any database, and publishing events to other services should use outbox/CDC patterns rather than treating the store as a message bus. Keeping streams short and applying proper domain modeling techniques are the key practices for performance.
Table of contents
Is event store a messaging tool?Is Event Sourcing performant as relational or document databases?What if streams get too long?Do we get strong guarantees?Should I share event store between microservices?Do I need to load all events, or can I use snapshots?Is Event Sourcing a global architecture concept?How do I publish events between microservices?1 Impression