2

Technically this question could relate to any database that performs in a similar distribute manner but given that I am specifically working with OrientDB I thought the question should be target as such.

For want of better terminology the conventional approach (for me in any case) for a distributed database is very similar to that of the architecture supporting the logic layer. A load balancer where all the queries are directed with an auto scaling group behind the LB that uses some metrics to spin up and destroy database servers on demand. As servers are dynamically added and removed Orient uses its multicast to synchronise the instances. Something like this:

enter image description here

It then struck me that this model could exist is a different format where each App instance has its own DB instance. The elegance is that you still get the same redundancy, but you don't have the cost of the extra db instances and you don't have the LB failure point. I know that the ration of DB instances and App instances doesn't necessarily need to be 1:1 but there is no harm in it. It also means that the code for the DB can be managed inside the app codebase as each new app instance that spins up configures its own DB and then connects up to the others to sync using some ENV VARS passed in at build time. Probably sensible to have a single fallback instance outside the ASG.

enter image description here

Clearly both models have advantaged and disadvantages. I also appreciate that there would need to be some specifics ironed out but are there any significant problems with this concept? Is there perhaps a better architecture that already exists?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.