3

This is in context of a distributed computing. There is a Service A which owns a database and hosts APIs for updating an entities in this database.

As time went by, the service has evolved and we are about to add a complex capability to this service. This capability can be separated out to a service of it's own. But it updates the same entity which service A owns.

Now what i'm not able to find a definitive answer for, is whether the new Service B should use Service A's APIs to update the entity or should it be allowed to directly access the DB.

  • This new capability is a capability of service A i.e, It is tightly coupled to service A .
  • If we were to give direct DB access, we would maintain the DB code in a common library

API:

Pros
  • Ownership boundary of the entities will be well defined and clear
Cons
  • Additional network and network latency

Direct DB access:

Pros
  • We can get rid of the un-necessary auth and network latency
Cons
  • Ownership boundary of the entity becomes blurry.

In my mind as the common code is in a library and we are just changing where the code runs, i don't see the value of using APIs

Overall my questions are:

  1. Does giving direct DB access really blur entity boundaries?
  2. Are there any long term cons of giving direct DB access which I'm missing.
Improve this question
7
  • 6
    Why should it be a separate service in the first place?
    – Jacob Raihle
    Nov 21, 2022 at 8:27
  • @JacobRaihle The main service has APIs for manipulating the entity. Now we are adding a feature which does some intelligent manipulations on the entity. These intelligent manipulations ultimately can be achieved by calling the existing APIs. Doesn't make sense to add another API "DoIntelligentManipulations" when the purpose of the service is to provide APIs to update the entity, which are already present. If we keep doing this we would need to add an API for each complex manipulation we think of. Am i thinking in a wrong direction here?
    – Sanath Kumar
    Nov 21, 2022 at 9:18
  • 4
    In my experience, developers are too prone to splitting things up, especially when dealing with microservices. If you are using the same database and a synchronized common library (so by necessity the same tech) - what are you actually getting by splitting it into two services? If, when you need to manipulate data in the database, your first instinct is direct data access - why does service A exist?
    – Jacob Raihle
    Nov 21, 2022 at 9:33
  • 2
    > what are you actually getting by splitting it into two services? A) The manipulations done by Service B is for an open ended problem. It can eventually evolve to depend on multiple other services for making decisions. The problem space service B intends to deal with can evolve independently of Service A. Hence a separate service.
    – Sanath Kumar
    Nov 21, 2022 at 9:38
  • 3
    If you share the database between services, the database schema becomes the API, possibly in addition to other APIs. This influences how the services must express their business logic. For example, “whenever PizzaService updates a Pizza, it also notifies Customer” could become “whenever PizzaService updates a Pizza, it also notifies Customer, and it will run a query every 30s to find Pizzas that have been updated by other services”.
    – amon
    Nov 21, 2022 at 13:29

4 Answers 4

Reset to default
6

Indeed, option 2 (direct DB access) makes the ownership of the shared entities, and the responsibility for their invariant unclear.

In the long run, maintenance risks increase. A typical example is an update of a property in one service, that fails to trigger some consistency updates required in properties that are important for the other service. Distributing it between services might not solve the issue due to transactional consistency issues.

You can keep the direct db access situation clean by using a shared library. In this case you must synchronise releases and deployment of both services (coupling). Or you may consider to enforce entity ownership and decoupling, for example with a microservice approach.

Improve this answer
9
  • > 1) A typical example is an update of a property in one service, that fails to trigger some consistency updates required in properties that are important for the other service. A) Can you give an example? In our case updates made by Service A will asynchronously trigger Service B. If Service A fails then it's ok for Service B to fail. > 2) Distributing it between services might not solve the issue due to transactional consistency issues A) We have transactional consistency on entity updates(using versioning in DynamoDB).
    – Sanath Kumar
    Nov 21, 2022 at 9:23
  • > 3) In this case you must synchronize releases and deployment of both services (coupling) A) This is not a hard requirement right? What issue can we see if the deployments are not synchronized.
    – Sanath Kumar
    Nov 21, 2022 at 9:27
  • @SanathKumar Re 1: Suppose service B keeps a computed property in the database for efficiency reasons, service A makes a change to in input of the computation and the asynchronous trigger to service B fails (due to a bug, network issue, etc.).
    – Bart van Ingen Schenau
    Nov 21, 2022 at 12:05
  • @SanathKumar Re 3: Yes, that is a hard requirement if you want to be able to perform schema/structure updates to your database. Just imagine what could happen if the two services have a different understanding of how the data in the database should be structured.
    – Bart van Ingen Schenau
    Nov 21, 2022 at 12:07
  • @BartvanIngenSchenau Thank you very much for this example.
    – Christophe
    Nov 21, 2022 at 19:39
4

Sharing a database between multiple application is known as an integration database. Not only does it have to consider the requirements of all of the applications integrating through it (which results in added complexity, often accidental complexity). It also increases coupling between applications, which affects various non-functional attributes of the system, such as performance, scalability, flexibility, and others.

Using an integration database is not recommended.

Improve this answer
2
  • Not recommended by whom? Presumably people who mindlessly go along with the latest trend.
    – Reinstate Monica
    Dec 2, 2022 at 22:11
  • @ReinstateMonica Not recommended by Martin Fowler and "most software architects" that he respects, for one (see the link in my answer). Just searching for "integration database" brings up several blog posts where people regret trying it or raise risks that need to be mitigated that make it not worth it for the vast majority of cases. It's one of those things that's extremely close to being a universal truth in software engineering.
    – Thomas Owens ♦
    Dec 2, 2022 at 23:06
2

Your dilema doesn't have a right / wrong solution. Both are valid architectures with prices to pay for it.

  • Microservice
  • Service-Based Architecture Style (as described in Fundamentals of software architecture, not to confuse with SOA)

Are there any long term cons of giving direct DB access which I'm missing.

Yes, most decisions are always a trade-off, for example:

  • A failure in App A can create problems in App B. (This may happen anyway if they depend on another one).
  • Security. Intrusion in App A can get info from App B.
  • You need to consider all apps before any DB change.

But there are also Pros like keeping ACID transactions, avoiding data synchronisation between dbs, simplicity and avoiding serialisation.

Does giving direct DB access really blur entity boundaries?

It can.

There is an strategy to solve it: partition the database. You can have the same physical database with different users that only have permissions to some tables. Information shared from other domains can only be accessed with a view (This view becomes the contract!!)

This can also be an intermediate step to keep the modularisation until you decide to go full microservice with some apps.

Improve this answer
-1

In software architecture everything is a trade-off, so you will hear different opinions. Direct DB access is easier, has better performance, and makes transactional queries straightforward. The negatives are increased coupling and all the other things mentioned in the great answers here.

An interesting recently published post is the the distributed computing manifesto. Read it to learn about the challenges and problems with direct DB access at Amazon many years ago, and what they did to fix them.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.