Microservices -> Approach to features/PRs from different teams to your service?

Question

Software design

Hello. In my work, I came across this thing. There are more than 500 microservices in live. Each group of services (3-10) is assigned a command.

Let's say there is a feature - it needs to be "carried out" through, let's say, three services. There are two ways to implement:

1) the team that needs to make its own local "feature" - splits tasks between "their own" and they make pull requests with the necessary changes to all three repositories

2) the team understands which services need to be changed and which - throws these requirements into three teams, where the service owners themselves are already sawing the functionality needed by other teams.

3) a hybrid of #1 and #2, depending on the load - the owners of microservices can "give advice" on how to do it, if possible, and wait for a PR, or decide that it's better that they do it themselves, but later - i.e. The "receiving" party decides, but basically, if the command is not loaded, the service owners themselves make the changes.

Why this question arose: we use approach #1. IMHO - this is pain and suffering. Moreover, for everyone.

a) for those who need a "feature" - every time they need to "pump out" other people's turnips, try to understand how the code and tests are organized there, read the architecture (which not everyone can), run all this somehow and test it locally, then to strain the team - the owner, so that they review - they also usually spend a lot of time explaining what would be needed like this and why.
b) those who ram services - it is impossible to "stand to the death" against "so-so pull requests". These are the ones that work, but ideally, for example, refactoring is needed - but this is unrealistic to do either within the framework of this pull request, or often within the framework of a particular pull request - it simply lacks the skill. As a result, we have what we have - often dirty code, the efforts of the owners themselves, and then those who make new PRs, are spent on cleaning and maintaining it.

All this leads to a complete refactoring after some time. And it's good if it leads. Those. minus everything. Plus - whoever needs a feature scales the number of forces thrown into it - conveniently. But in the end - even in the medium term - it does not pay off. Guidelines, runbooks, standardization of repositories and approaches help only very partially, because. as a result - everyone writes a little differently and under their commands. There was a real case when a person from the frontend (service on nodejs) came to the backend service with a feature - he made a pr, which generally works, but architecturally it's a little hell. Everyone closed their eyes, because. no one really wants to be a toxic person - you yourself understand. As a result, after six months, it was no longer possible to support it, and there was a complete refactoring to suit the style of the team and "nearby" services.

And I'm very curious if there are people here who work underground > 50 microservices + different teams and use #2 or #3 approaches.

Maybe there are links to habr / foreign resources with discussions? I would be grateful.