We are migrating a desktop application into web based Spring Boot micro services application with a client imposed mandate of using their existing MySQL database, so all micro services share a common database.

Since its a SQL database we chose Spring JPA (Hibernate).

During project setup, our architecture team generated entities via Hibernate Tools into a "db-commons" project and also added Spring JPA repositories to this shared library citing reusable code.

Although shared entities sound harmless to me, I vehemently opposed idea of having shared repositories, as -

  1. It violates S of SOLID. A micro service should only see & operate on data it owns.
  2. Developers under pressure would directly user these repositories in other services to modify data owned by other micro services.
  3. It leads to duplicate code and possibly missed validations.
  4. It could lead to concurrency & data issues at scale.

Are my concerns wrong ?

If right, did I miss any possible negative impacts (present/ future) ?

  • The SOLID principles are object-oriented principles (not laws) that apply to classes, and nothing else. Dec 18, 2018 at 15:44
  • 1
    If each microservice has the same database, I am not sure why would sharing the repository layer be a problem. However, in my opinion, each microservice should have its own database. If all microservices are sharing the same database, you just moved your monolith desktop-based app into a monolith REST(or whatever else) based app. It is probably even worse than desktop now because you have to deal with network requests overhead.
    – bobek
    Dec 4, 2019 at 1:17
  • 1
    The whole idea behind microservices is to remove a single point of failure in your system. If one microservice fails, the others are still operating. In your scenario, if your database engine fails, all microservices fail, and your whole system is down. A typical characteristic of a monolith system.
    – bobek
    Dec 4, 2019 at 1:25

3 Answers 3


I vehemently opposed

Vehemence makes others stop listening and, at the same time, it limits our perception of the problems, hence our capacity to find solutions too.

To my experience, we become vehement at defending or opposing ideas we don't fully understand. A sign of this is when we are unable to explain clearly the why and how.

Although shared entities sound harmless to me, I opposed the idea of having shared repositories

Microservices architectures are anything but a trivial thing. Splitting the persistence is among the hardest thing to do. This is something easier to say than done and thus why so many "gurus" write about "how things should be" but none say exactly "how to do it".

When we read about the subject on the internet, we have to recall that we don't know what led the author to reach his/her conclusions. Or we do, but we don't share exactly the same problematics.

Making decisions upon someone else opinion only leads to mediocre decision-making, so don't be dogmatic. Don't defend vehemently opinions of strangers. Be pragmatic. Put everything you know about the subject into the context of the project, do some proof of concept and choose what works for you. Start with the simplest solution and evolve it as the needs arise.

  1. It violates S of SOLID. A microservice should only see & operate on data it owns.

One data source per service is, theoretically, the ideal scenario but it's not a rule written in stone. It's not like Martin Fowler will appear and eat our soul if you don't do it. We segregate data sources when we find a good reason for it.

This kind of architectures have been promoted by companies with large monolithic systems which maintenance became so hard and expensive that made them less competitive in the market. These companies needed a way to articulate different SDLC so they could reduce the time-to-market, parallelize developments, deploy new features and take'em off any time, etc. At some point they found that a single database was limiting their capacity to make this possible, so they decided to split data sources too. Those were decisions driven by business goals2, not theory or dogmas.

Any architectural decision must be driven by business needs which are addressed to meet the goals of the company. Some of these goals are self-evident, others are not. Segregating data sources must be driven by needs. Let'em arise first then apply the solution.

  1. Developers under pressure would directly user these repositories in other services to modify data owned by other microservices.

    Not necessarily, we can isolate repositories in several libraries and choose only those we deem necessary for each service.

    In turn, we can make services connect to the data source with different profiles, each of which with different ACLs. Many of the database support RBAC. Take advantage of it.

  2. It leads to duplicate code and possibly missed validations

    It leads to code-reuse and that's good. The libraries don't have to provide us with concrete data models if they were "abstracted" properly. Sometimes, the only we need is an interface to implement or an abstract class to adapt. The code-reuse in repositories is not the data model, is the logic around persistence. Regarding the missing code, if that code worth reuse, it will be encapsulated in the libraries alongside with the repositories.

  3. It could lead to concurrency & data issues at scale.

    Or not. Premature optimization is the seed of evil. Don't oversize the system until you have reasons for it.

    The concurrency could be problematic if several services overload the data source so that the rest of the system suffers the consequences. That's a good argument for us to segregate the data source, but we have to wait until this becomes true. As for the race-condition over the data, it also happens in high decoupled MS architectures where it's even harder to deal with.

Are my concerns wrong?

You are theoretically right, however, you are not being practical enough. You are not paid to implement state-of-the-art architectures, you are paid to solve problems (today's problems) with whatever you have at hand.

did I miss any possible negative impacts (present/ future)?

Yes, but they only matter if they matter.

Shared libs mean that in order to take advantage of code-reuse, other services must be implemented with the same programming language. That's quite contrary to the MS philosophy1. But it's not necessarily bad if all your developers only know that programming language.

Code-reuse also couples SDLCs since changes in the common source code might penalize the delivery strategy, hence the time-to-market. But it helps to find what services could be tightly related to each other. A signal that they could become a single service in the future.

Reality vs perception

Reality is all about perception. You can provide the "perception" of having different data sources when there's only one "real". Make it real when there's a real reason to make it.

1 - MS architecture is all about freedom of implementation and resilience

2 - Companies have goals and they set strategies (what to do) and we are asked to make them possible. Our job is the tactical one (how to do it).

  • 1
    Note that I didn't address the answer to find arguments for you (OP) to go with against your tech leaders. I rather focused on giving a wider perspective of the things and how you can achieve some goals without draconian solutions.
    – Laiv
    Dec 13, 2018 at 16:39

This shared library could exist for some time because you are in the middle of a migration, but you need a plan to vanish this library as soon as possible.

Using micro services with a shared library is considered a bad smell in some cases, but understandable if you are trying to break a monolith application in small peaces (services). I think we can consider your desktop application as a monolith application.

Deal with a shared library that contains entities and repositories sounds a bad smell case to me. You will need to deal with a lot of changes on this guys and, probably, you will be sometimes forced to upgrade the version of this shared libraries in all micro services. But as I said, if this situation is temporary until you identify the right services owners of each database and remove this shared library on the future, for me is an acceptable temporary solution.

Remember: generally, the micro services is a good idea when they are very independent. Think if you really need these micro services that you created and if a monolith, before break on micro services, it's not a better choice until you understand what micro services you need.

  • Many java microservices will use Apache commons. Or google gauva. Probably tens of thousands of microservices all have those libraries. Does the fact you wrote it somehow make it evil? Shared entities sounds like a problem, but once that bridge has been crossed a shared library to manage that mistake sounds eminently sensible Jul 13, 2019 at 23:00
  • @RichardTingle the question is about share database entities using a library. It's not the same thing if compared to Apache Commons and etc.
    – Dherik
    Jul 13, 2019 at 23:04

First of all your microservices should be operating on their own DBs... now even though that's not the case, it's generally a good idea to architect your application in a way that allows for this, or at least doesn't make it obvious that the db is being shared.

I would strongly suggest keeping repositories as useful to an individual MS as possible, and not allowing the sharing of repos across MSs. This way it remains very clear as to who owns what within the system, and also keeps the idea of a shared database away from any other layer of your applications.

Your Answer

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