Looking for some feedback on our architecture

EventStoreDB
#1

Hi guys!

I don’t really know if this is a place for this, if not please let me know.

is this architecture sound for scalability?

Some background; can be skipped :slight_smile:

Me and a friend are doing a startup, and we’re planning on going for EventStore as the main persistence. We’re implementing a finance SaaS for accountants managing the economy of housing co-ops. We will be doing a lot of interrest calculations and maybe some forecasting. The idea of having an audit log built in, and the possibility of doing corrective actions and repopulate the views seems like a good idea. Since we’re starting with a niche and planning to expand, we want a highly scalable architecture. We will be using Azure or EC2.

Any feedback is appreciated :slight_smile: We will also be adding a queue somewhere to not lose any messages on node outages, but we haven’t decided how yet.

#2

Hi,

One thing worth noting is that the Event Store is a queue in itself. Is there a reason you’ve separated out sagas (probably actually process managers to give it the correct name from EIP?) in this way?

Thanks,

James

#3

Hi, thanks for the response! :slight_smile:

I was not aware that the Event Store can be used as a queue, but availability issues will sadly prevent us from using it as such. We will be running our app in the Azure cloud, and will be using the Single Node as we boot up the company. Using that single node as a queue will be a single point of failure, so we will use the Azure Queues.

I don’t know process managers from EIP, haven’t gotten around to reading it yet :slight_smile: Azure is also the reason why I have separates sagas to a distinct module, as I want it to be independently scalable from the other “modules” The plan is to be able to collapse all modules into one Azure Worker Role, and then be able to scale them out independently. This gives is the smallest idle footprint possible while maintaining flexibility in scaling.

If there are no obvious flaws here, I’m looking forward to implementing this and see the power of ES first hand, it is a very sexy idea for a startup with a wish to not miss any future opportunities :slight_smile:

#4

Remmember everything must be idempotent then as you can’t save your managers state and push message atomically. This happened in the pnp implementation as well.