We are beginning to add third-party integrations that all have to do with a certain business concept. (If it helps to make things concrete, in our case it's "measurements," i.e. third-party partners that track whether customers have visited websites, downloaded apps, etc.)
Tech-wise, each of the third-party integrations work completely independently. Most of them require storing some metadata like API keys. One of them actually requires a new backend service because we need to write some business logic that orchestrates data via multiple GraphQL endpoints.
But because of this service's existence, a question has come up: Should we make this service into the "measurements service", housing all metadata there as well as the GraphQL orchestration for the one particular integration?
(If we weren't to do that, we would follow our current paradigm of storing metadata close to the accounts they're related to, in the accounts service.)
It seems natural to say, "Yeah, perfect, put all measurements-related stuff in one service over there." But is that a relevant reason? (I guess if developers wonder, "Where can I find metadata and logic related to measurements?" then it's all in this one repo?) It's possible future integrations will require us to build more "orchestration" endpoints, or require us to store more complex metadata, and we wouldn't want to create new services for individual integrations. On the other hand, it doesn't feel like a very principled approach to say, "Well, we need a new service for X anyway, so let's put Y and Z here too."