When is communication over-communication ?
Strong communication could indeed be a symptom that something is wrong, for example that a component was split into parts but shouldn't have been. But it could as well be the evidence that teams that have something in common work together very effectively.
So how to make the difference ? It's not a question of quantity, because IMHO, the most frequent case is absence of communication: teams work in silos thinking they live on an island. This always result in misunderstandings, unexpected surprise (what ? they changed the API two weeks before our release ?) and frustration.
Self-introspection questions: what's the quality of the communication ? Is it useful ? Is it constructive ? What's your negative feeling about it ? Is this negative opinion shared by your teammates ? And by the members of the other team ? Why do you think "it's too much" ?
Structure of the business domains
If there is some common functionality or domain parts (as it seems for your gateway), what would be the best solution according to you: repeat/redevelop/reinvent a new gateway for each product or isolating the functionality ?
So maybe the shared component is exactly the architecture needed and your team is key to the success of all the others. But if the other team all rely on it, isn't it normal that you involve them as stakeholders in the decision ? After all, if you were in an application team, you'd have frequent meetings with your customers for gathering the requirements, demo new user stories, and collect their impressions !
Self-introspection questions: are the communication useful, i.e. about requirements and interdependencies ? Or is your team not daring to take some decisions on its own and over-involve the stakeholders in the teams decisions ?
Bad quality, for example if there are too much bugs delivered, could cause extra-inquiries from the other teams. This would be some kind of communication that is symptom of bad software.
Bad design as well. If your component is not SOLID, you and your customer will have unnecessary discussion, due for example to a tight coupling that could be avoided with interface segregation and dependency inversion.
Missing information could also be artificially cause over-communication. A good reference documentation (attention: do not over-document ;-) ) and some release notes can really help to avoid unnecessary discussions.
Self-introspection questions: are you proud of what you deliver ? And would you enjoy consuming the gateway if you were in another team ?
With the little information I have, it's difficult to give an objective opinion on what's happening.
But over-communication is not necessarily a software design issue. It can be a problem with the communication and collaboration practices. Fortunately, these can very well be improved if there is awareness.