Hosting and Scaling?

[mikecann]

Im wondering about how to host and scale Resolve? I think I have seen it mention on some issues that you choose serverless. I agree serverless would be awesome but there are definately some difficulties with a serverless Event Sourcing solution (I have built one before and it as HARD to get right with all the possible edge cases).

It would be awesome if you could offer some guidence on how to do it. Obviously you have your cloud offering you are working on tho so I understand if you dont want to give too much away. You have a fine line to tread there I guess..

[superroma]

reSolve local is a node app, so you can host and scale using any container management system.
reSolve 0.28 is tested in multi-instance mode, so it should work in the cluster without problems and additional configuration.

Here is issue with discussion of details:
#1680

Regarding serverless cloud hosting - if you want to try an early preview, send email to reimagined@devexpress.com, we will send you an invitation

[mikecann]

Haha I found the portal to resolve cloud myself and signed up a couple of months back, im not sure if its the same thing tho. Ill send an email.

reSolve 0.28 is tested in multi-instance mode, so it should work in the cluster without problems and additional configuration.

So a single instance of resolve is able to both handle the write side and read side? And it is able to do it in a stateless manner and cordinate with the other instances in the cluser? So you can simply scale instances of resolve horizontally to add more capacity?

[superroma]

Regarding portal - it is closed at the moment.

Several reSolve app instances can work well together without additional configuration, so yes, you just scale them.
As i mentioned, concurrent writes are kept consistent using optimistic locking. For read model notification, all instances are registered in the event store, and instance that modified event store notifies others, so they can pull new events and apply to the read models.

This means that in case of central read model DB, all instances would try to apply the same updates to the read model, but only one would win. This is probably not an efficient approach, but surely - the simplest thing that will work in all cases.

Please note that instances can have different configurations, so some of them can deal with write side, some with read side. Also, it is possible that each instance will have its own read model storage (local db).

[mikecann]

Okay thats very interesting.

For read model notification, all instances are registered in the event store, and instance that modified event store notifies others, so they can pull new events and apply to the read models.

Just wondering how you facilitate this inter-node communication? Redis pub-sub?

Please note that instances can have different configurations, so some of them can deal with write side, some with read side. Also, it is possible that each instance will have its own read model storage (local db).

Ah thats interesting, would like to see that in action. I wonder if there is a way for us as a user to know which parts should be scaled more than other parts?

[superroma]

Just wondering how you facilitate this inter-node communication? Redis pub-sub?

No redis there, just one instance notifies others via HTTP call. This is just poking "go check event store".

I wonder if there is a way for us as a user to know which parts should be scaled more than other parts?

I really hope this can be handled outside reSolve app. After all it is just a Node expressjs app.