I vehemently opposed
Vehemence makes others stop listening and limits our perception, hence our capacity to find solutions too.
In my experience, we are 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 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 do what he/she purpose. Or we do, but we don't share exactly the same context.
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.
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. We segregate data sources when we find a good reason for it.
This architecture has been promoted by companies with large monolithic systems whose maintenance (and operations) became so hard and expensive that became progressively less competitive. They needed a way to articulate the architecture, so they could reduce the time-to-market by parallelizing developments, deploying new features and taking 'em off at any time. At some point, they found that a single database was limiting this capacity so they decided to split data stores too. Those were decisions driven by business goals2, not theory or dogmas.
Any architectural decision must be driven by business goals.
Developers under pressure would directly use 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 databases support RBAC. Take advantage of it.
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 is worth reuse, it will be encapsulated in the libraries alongside the repositories.
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 highly 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 the opposite of the MS philosophy1. But it's not necessarily bad if all your developers only know one programming language.
Code reuse also couples SDLCs since changes in the shared source code might penalize the deliveries, 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).