Projection with partitioning by id

I recently came across a blog post on/about EventStoreDb with the catchphrase to keep streams as short as possible (at least this is how I understood the post).

This made me think about the following scenario where I’d like to know, if this is a valid approach (means: does it make sense at all)?

Given a domain entity Location with the events LocationAdded, LocationEdited (for simplicity in this case: the entity is always updated completely in one event), LocationPublished and LocationDeleted. Each event carries an entity id. All events are put into the same stream - e.g. location. Additionally there is a separate read model database with a database entity that matches this domain entity.

I would now create a projection that partitions the events by the entity id within the event. The projection keeps the current state of the location and hence updates the state with the data from the processed events. Finally, the projection outputs to (outputTo) a stream location_{0}.

I have a worker process running which subscribes to $all (or similar) with filter on location_* and simply puts the content of each stream event to the read model database.

Is this a valid approach? Or would it make more sense to have the worker subscribe to location instead and process the events on its own in order to avoid multiple streams / multiple projections (as this could be used for other domain entities as well)?

The general pattern is to have a stream instance per entity
I.e Location-[ID] where location is your stream category, and [Id] your entity Id
This allows to work on a per entity basis for all requests that need to append events.

From the consumer side, the part that needs to work on all locations , then you can either subscribe to all event and ignore the one you don’t need or in the case of ESDB use categories : $ce-Location

( genreally speaking, I always begin by subcribing to $all and then go to categories when observable performance in case of complete rebuild of read models is not good enough)


review the standard projections
This is a decent description of the type of functionality the Category projection provides via the $ce stream. Via some naming conventions and a slightly different approach. :slight_smile: