Hi
I’m trying to create a master data repository based upon EventStore but I’m in doubt regarding creating one stream to host multiple types (customer, employee, department etc.) or would it be better to create multiple streams – one for each type?
In the end I would like to create a projection on each customer/employee.
With regards
Jens Christiansen
usually it would be a stream per instance.
We normally stick with one stream per aggregate ID as the raw streams, then use projections to aggregate.
Hey,
The only gotcha I found with one stream per id is that if you
subscribe to EventStore on the all stream, and write to another
EventStore, then performance is horrible since you can't batch write
on the new one. We use this method for blue/green deployments and had
to go with one stream for the whole app to make it work.
/Rickard
So when you load an aggregate you read the entire eventstore? Or do you keep the entire application state in memory?
/Peter
Hey Peter,
I dehydrate from the read model, no choice. 
I wish there was a way to bulk write to multiple streams in one call,
then it'd be perfect.
/Rickard
The problem with bulkwriting multiple streams is it completely breaks if you want a sharded environment (which is otherwise pretty trivial to build). We have considered the use case in the past for a single replica set and will look back into it, perhaps documentation warning about possible future problems it is enough.
+1 single transaction for multiple streams has often been something I wished eventstore allowed. I have to code around this deficiency often. I've been using ES for 4 years and have never needed to shard data. It would be nice if it were optional in a non-sharded environment.
Hi Greg. It seems the two options presented in this thread are:
One stream for the whole app
One stream for each account, like account-1, account-2
No one is mentioning streams set up like:
accounts
transactions
statements
I am leaning this way as a first time user, but am afraid I am thinking in 3rd normal form tables.
My app will take in agile teams, track their schedules and calendar events. It will grow into tracking users in the teams and a skills matrix for each for charters, etc.
I can see the domain pretty well, just not the optimal streaming strategy.
easier to project from more granular (type-id) to more general (types) than the other way around I think
how to delete a single aggregate out of the system for legal reasons in a single-stream-per-aggregate-type system? requirements differ, of course