What is the right way to do microservice ??

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?

Comments

[J Mac]

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:

[Tom Nijhof]

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

[Mykhailo]

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...

[Lin Pengcheng]

The unification of Microservice, OOP, FP and Warehouse/Workshop Model

Programs = Algorithm + Data Structures
---- Niklaus Wirth, Turing Award (1984), Father of Pascal

It’s better to have 100 functions operate on one data structure
than 10 functions on 10 data structures.

---- Alan Perlis
the first recipient of the Turing Award (1966)
A founding father of Computer Science as a separate discipline

• 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 Microservice and Intelligent-thread

We 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

  • The information system integration layer acts as a individual system
  • A unified abstraction layer (virtual database, virtual data warehouse) of enterprise global data, external data requests for any subsystem are requested from warehouse(virtual unified db) without knowing which other subsystem to obtain them from. Achieve the unity of the global system.
  • The middle layer and data routing of system interconnection.

See also:

• The unification with Information System Integration Model
• 10 Principles: Single Leader and Unified Scheduling
• Overview of the Warehouse/Workshop Model
  • Warehouse ...
  • It can have no container, ...

so, 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).

---

It is the perfect theory if a theory is based on mathematics and meets the five basic principles of "Simplicity, Unity, Order, Symmetry and Definiteness" in science, industry and aesthetics.

Traditional IT theory (OOP, FP and hardware architecture, etc.) are pseudoscience. they belong to what physicist Wolfgang Pauli said "Not Even Wrong".

Keep it Simple and Unified.

Computer science is essentially a management science, and vice versa.

Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry.

---- Lin Pengcheng

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 Model

• Success Story