I am exploring microservice-based architecture and have a doubt:
Should all my microservices have a common database?
While designing the application, I can take either of the following two approaches:
Approach 1: All microservices have a common database
Approach 2: All microservices have their database
With approach 1:
- I can take advantage of the relational schema of the database.
- However, since the database is common, when it comes to scalability, I am afraid it would act as a bottleneck.
- Also there would be unnecessary code duplications and I don’t think this approach falls in line with the mantra of “Separation of Concern”, that is the main motivation behind choosing microservices in first place.
whereas with approach 2:
- I think this approach would be more scalable and easier to maintain separation of concern.
- However, with this approach I don’t get to enjoy the benefits of Relational Schema which would add to the code complexity.
Dear readers, I understand that the system requirements play a significant role in making any design decision, however I wonder, which of this two approaches would be more preferred in terms of scalability and be considered to be a better system design?
Top comments (4)
I do not know your application so this might not apply but there are an other option.
Have a micro service around the database. The other 3 services talk with this Fourth service. This db service has all the logic around the db and simplify it to a few rest api endpoint.
I find this strikes a good balance in some solutions. You have only 1 service accessing the database but still multiple services using the same data
All books I've read point to #2! But... I'd go further and check the book Software Architecture Patterns for Serverless Systems. The author suggests a permanent event bus between all (micro)services of a given subsystem:
Hi! I have just started learning about microservices, but as far as I understand, option 2 is the best way to start.
The main reason is that each service decides which database (SQL, NoSQL, no DB) it uses and what data structures it works with. Moreover, direct database access between services is not allowed, so there is no tight coupling between services. This makes independent releases possible.
Here is an interesting article: microservices.io/patterns/data/dat...
The unification of Microservice, OOP, FP and Warehouse/Workshop Model
Warehouse: Dataservice, Data Management, Object state, Data Structure, database. Obviously, the database should be as global and unique as possible.
Workshop: Microservices, Independent Systems, Object method, pure function, functional pipeline, Algorithms, Functions.
We can split a large system and evolve it into a microservice system.
Warehouse: Object state, dataservice, data management
Workshop: Object method, Microservice, Various independent systems.
See also: The unification of
MicroserviceandIntelligent-threadWe can integrate many independent systems and evolve it into an integrated system.
Many large enterprises have independent information systems produced by different manufacturers and need to integrate. We can integrate many independent systems and evolve it into an integrated system.:
Workshop: Object method, individual subsystems
Warehouse: Object state
See also:
Information System Integration Modelso, Workshops (object method, microservices, independent systems) are decentralized and independent, but The workshop is connected with data services (object status, warehouse) to form a system (large object).
Reference
2018.03.18, The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
The unification of OOP, FP and Warehouse/Workshop Model
Traditional IT theory (OO, FP and hardware architecture, etc.) VS. Warehouse/Workshop Model
The unification with
Information System Integration ModelSuccess Story