Using Event Store in separate bounded contexts

EventStoreDB
#1

How would one go about using Event Store in separate bounded contexts? I am not talking about using Event Store to communicate between bounded contexts, but merely the fact that multiple BCs sometimes want to use an event store but still be independent of each other.

When using a database server, be that NoSQL or relational, there is a concept of databases so I can host multiple databases on the same database instance.

Is there any recommendations to solving this? For example I think most of our BCs will use catch-up-subscriptions using SubscribeToAll(), but we are not interested in events from different BCs. Maybe it can be solved entirely using namespaces for the events, but I appreciate any thoughts on this.

  • Morten.
#2

Hey

I used category to distinguish between ‘databases’. I would subscribe to events of one category in order to process events from a BC. This was I was able to use the same ES instance in multiple BCs.

Szymon

#3

Yes this is quite easy to do. As an example you could just use a name prefix on the streams. Then you could write a simple projection to bundle all the events from a given prefix into a single stream.

imagine [bcname]-[stream]-[something]

(this is not copy/pastable just to show idea).

fromAll().

when({

$any : function(s,e) { linkTo(e.streamName.substring(0, e.streamName.indexOf(’-’)), e)}

})

Now if your names were say sales-whatever-1022 you would have a stream /sales/ with only the sales events in it that you could use a catch up subscription on

Cheers,

Greg

#4

It would be useful to mention ‘category’ in the documentation (wiki). Can’t find anything about it.

#5

“Category” is a projections concept. The docs are currently being written for projections as they will be released soon. There are some works in progress already posted in the documentation but not linked off the main page (go to pages) they will be completed over the next week or so.

#6

The only problem I see in this approach is that there is no (easy) concept of individual backup and restore since all events are in a single “database”. Have you ever considered to introduce something similar to multiple “databases” (i.e. separate physical storage) per node?

#7

Yes we have considered this (its even on the timeline!). How many tenants are you looking at running?

#8

We have considered this (it’s on our backlog).

The other thing you can do of course (in OSS at least) is run more than one node on the same box (and use something like nginx to route requests to the correct instance based on hostname or similar if you don’t want to open a ton of firewall ports…)

#9

We have up to 15. Currently we spin up a node instance for each of them…

#10

for up to 50 that seems reasonable

#11

BTW multiple instances is a lot simpler if you’re using the commercial version - the manager can be a watchdog for multiple nodes.

#12

Greg,

How did you get this number? :slight_smile:

for up to 50 that seems reasonable

What will happen if there 52 instances running?

Yevhen

9 сент. 2013, в 21:52, James Nugent james@geteventstore.com написал(а):

#13

we’ll come back to that in the not too distant future since we have to provide fail over for certain customers. Its in our queue. But thanks for mentioning it

#14

Jokes aside, do you expect that native support for physical multitenancy
will greatly improve memory/CPU usage compared to running multiple instances on the same node?

#15

yes. though well configured it would be equivalent. the trick is making it easy.

#16

Greg and all,

Sorry for re-opening the year-old thread but I am curious if there have been any development regarding:

Greg Young: “Yes we have considered this (its even on the timeline!).”

or anything else related to multitenancy?

Best,

-Leo

#17

It is. Competing consumers was given precedence but it’s on the timeline looking right now to be early next year though schedules get juggled

#18

Thank you!

#19

+1 Thx

#20

Btw much of the work for sharding/multitenant overlaps (tb sharding is just putting multiple tenant instances into one set … Management etc is all the same)