Do most usecases of eventstore assume a 1 to 1 correspondance between an aggregate and a a stream.

EventStoreDB
#1

So I have just got started with event store and am reading through the documentation. I was wondering if anyone could clarify the following point.

Aggregate IDs are the only partition point in the system. No matter how many aggregates exist or how they may change structures, the Aggregate Id associated with events is the only partition point in the system. Horizontally Partitioning an Event Store is a very simple process.

http://docs.geteventstore.com/introduction/3.9.0/event-sourcing-basics/#performance-and-scalability

This seams to suggest to me that each aggregate belongs in its own stream. so instead of making a stream called “people” you might have a stream called “person-1234”. What level of granularity do people normally split there streams too?

#2

An extension to this question is if you do use a stream per aggregate where do you store the information to lookup the appropriate aggregate id. If there is a stream per person then how do i find the id of the user with email “me@example.com”

#3

You don’t query the event store like that. You shouldn’t be fetching a user by email unless the email is the id.

#4

I don’t really “query” the event store ever. I subscribe to all events and project into Neo4j or ElasticSearch, and then use those query languages to get whatever I want, depending on use case.

#5

In the same boat here going into Elasticsearch. We simply read $all and filter out system and other events. The alternative to get things shaped differently is to use projects, I believe. Which is still in beta, I also believe.

#6

Until you are doing 1000s of events/second ^^^ is usually the best
option. Its network stupid in that it sends things over the network
that are not needed but its quite simple.

#7

Write your own projection for this.

#8

Or if you write your stream ids like aggregateType-id, with the by-category projection, you can subscribe to $ce-aggregateType. Which is very handy.

#9

Thanks all. I guess I wasn’t properly using projections. I had a usecase that was for support we want to take a users current email address (‘cant be the id as it might change’) and then see all events associated with that. But I guess the answer is a projection should be used to map email to aggregate-id and then using the aggregate-id we can inspect every event in a stream