Question: Querying across services, Database-per-service or One database

[Mohamed Belkamel]

Hi am building a simular project, using event driven microservices architecture, and am stuck thinking wether i should use a single Database and connect all services to it, or do a database-per-service approach, i could brainstorm some reasons why doing a single database is bad (sharing Model schema between multiple services)

but the advantage am looking for in the single Database approach is: you can query any table you want, which is a thing i can't do in database per service, soo my question is how would you go about querying data from another service, let's say UserManagement needs data from ticketing service for exemple, any approach aside synchronously calling the other service using http.

Am using rabbitmq to broadcast the creation of a document to other conserned services

[SuspiOwl]

Might be helpful (from microservices.io)

There are various patterns/solutions for implementing transactions and queries that span services:

• Implementing transactions that span services - use the Saga pattern.
• Implementing queries that span services:
  • API Composition - the application performs the join rather than the database. For example, a service (or the API gateway) could retrieve a customer and their orders by first retrieving the customer from the customer service and then querying the order service to return the customer’s most recent orders.
  • Command Query Responsibility Segregation (CQRS) - maintain one or more materialized views that contain data from multiple services. The views are kept by services that subscribe to events that each services publishes when it updates its data. For example, the online store could implement a query that finds customers in a particular region and their recent orders by maintaining a view that joins customers and orders. The view is updated by a service that subscribes to customer and order events.

---

https://microservices.io/patterns/data/shared-database.html

The benefits of Shared Database pattern are:

• A developer uses familiar and straightforward ACID transactions to enforce data consistency
• A single database is simpler to operate

The drawbacks of Shared Database pattern are:

• Development time coupling - a developer working on, for example, the OrderService will need to coordinate schema changes with the developers of other services that access the same tables. This coupling and additional coordination will slow down development.
• Runtime coupling - because all services access the same database they can potentially interfere with one another. For example, if long running CustomerService transaction holds a lock on the ORDER table then the OrderService will be blocked.
• Single database might not satisfy the data storage and access requirements of all services.

---

https://microservices.io/patterns/data/database-per-service.html

Using a database per service has the following benefits:

• Helps ensure that the services are loosely coupled. Changes to one service’s database does not impact any other services.
• Each service can use the type of database that is best suited to its needs. For example, a service that does text searches could use ElasticSearch. A service that manipulates a social graph could use Neo4j.

Using a database per service has the following drawbacks:

• Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them.
• Implementing queries that join data that is now in multiple databases is challenging.
• Complexity of managing multiple SQL and NoSQL databases

---