We are creating microservices using springboot & Camunda(7.10).
Camunda BPM will be running inside a springboot app per microservices. We can see there are quite large number (around 25+) of springboot app is getting developed to cater domain driven design principle and inside these app there will respective camunda BPM process will running .We also want that applications to be highly scalable and resilient to showcase the our approach using camunda for POC. We will be connecting with Oracle 12C DB .
Now our question is whether we should connect to a single DB(same schema) for all of these spring boot app ? or we should separate DB schema for all of these different app ? What Strategy should be considered here as per your best practice ? Operational aspect need to be keep in mind as well.Also these app will be deployed in a container and the plan is to scale them(i.e more number of docker instnace)on load in future,
The answer is as always “it depends”. The are some implications from the decision. You will surely find discussions about it if you search; I shall not write it here again. You just have to decide what solution better fits your requirements.
Thanks for pointing this .Really there are quite lot of threads and am quite confused of these. My initial take was to have single DB instance for all these spring boot app . With that one of the opertional wishlist - to have all process diagram in a single dasboard/cockpit window will be fullfilled . But I am bit worried whether that will cost any performance issue ? .Whether the schedule async job will be processed by respective instance as all will be store in the same table ?. If there is a migration from one version to another version of one process diagram where that can create any issue ? Post opertaions hitches are not very clear to me with this approach . If anyone of you kindly point those operational aspect with this single DB /scheam options.
Hi Anisk,
I would suggest you need to identify your requirements in terms of;
Scalability
Reliability
Operability
Availability
Performance
Throughput
etc…
If you use a single DB instance for all services, you probably maximise simplicity, however you may sacrifice the others. You could use a clustered or DB tier with failover which could improve availability, however you could violate the principal that micro-sevices share nothing… At the other extreme, you could have a dedicated, co-located DB per node with a service per node. This then shares nothing and can provide the best performance and scale, however you may loose reliability. In addition, your operational/deployment architecture may depend on your resources. If you use AWS cloud, then elastic beanstalk and RDS may influence your choice. If on premises, you may be constrained. My suggestions;
Prioritise your non functional requirements into the top 3.
Identify those NFRs you are prepared to de-emphasize.
Identify deployment constraints (cloud/on prem, cost) etc.
Then assess different architecture patterns against these.