Should all my services connect directly to a DB or should I put an API in front of every DB? [closed]

Question

I have a small system written in Go with aprox 10 services, and 3 DB (InfluxDB, Postgres, Blockchain) Each service use InfluxDB (some service read, other write), and postgres ( Readonly).

I see 2 options:

1. In all my services, I use a client to connect directly to DB

   • Pros:
     • I already have it this way.
     • It is easier to write, and more flexible maybe
   • Cons:
     • All services are coupled to 2 or 3 databases,
     • Testing is being quite difficult

2. I write a REST API in front of InfluxDB, that manage all queries, and systems just invoke those URLs to execute a query

   • Pros:
     • Unloose all my service from a Influx / Postgres dependency
     • Maybe mocking is going to be easier
     • Refactoring to ElasticSearch is easier
     • Centralized credentials
   • Cons:
     • more work
     • more tedious ?
     • Will it bring me something valuable ?

I am looking for advices to take this decision, or maybe, I am asking myself, Will it bring me something valuable ?

Answer 1

In Microservice architecture, often the goal of Microservices is to find "seams" and break up the services along those seams.

If you have multiple services "coming together" in a single database, then you're, in essence, breaching the seam.

It appears you're splitting your seam in the wrong way. It's my understanding that any given service can definitely use a db connector service to connect to its responsible DB. That's fine.

But to have multiple services essentially be separate EXCEPT at the DB level might be troublesome.

It violates, for example, the idea of having separate teams working on each service. Which is one goal of the microservices architecture. To keep teams focused on specific functionality.

Also, the shared DB violate the cohesion that Microservices are aiming to create. In essence, you have Adhesion on the DB level.

Then there's a question of how brittle those shared databases are, in terms of entities. Can their structure be preserved if they're serving multiple services?

... and I'm wondering about any logic at the database level that's cutting across the service seams by having service entities interacting with each other in the DB, in a way they shouldn't be.

You could do a single API for the DB, but this presents as a somewhat problematic solution because the monolithic database service ends up breaking cohesion for the consuming services.

The proposed Solutions, as I understand them:

• On each service build a layer to communicate with the DB
• On the DB, built an API for the Services to consume

I'm not completely sure which is the best but they both abstract away the core issue: Adhesion at the database level.

My suggestion is identify seams in the DB and start "breaking" them apart and to do that process incrementally over time.

It'll solve the testing issues you're having as well. Increase Service cohesion and increase decoupling as well.

Answer 2

If the Go application is itself a server, then I see no reason why you need to build an intermediate server to handle the DB interface. At that point you're probably over-designing things. Use the standard client libraries, that is what they are for.

If the Go application is the client (such as a command line tool) that is used 'out in the wild' on computers you don't have control over (such as end user machines), then yes, such an API would be a good idea so that you are not exposing your database to the outside world - along with all the risks associated with doing that.