Requiring that no service is depended on by two services is nonsense.
You absolutely want the same identity service behind all of your services that rely on an identity concept (and no, you can't just say a gateway should be the only thing talking to an identity service - there are real downstream uses cases such as when identity gets managed).
Similarly there's no reason to have multiple image hosting services. It's fine for two different frontends to use the same one. (And don't just say image hosting should be done in the cloud --- that's just a microservice running elsewhere)
Same for audit logging, outbound email or webhooks, acl systems (can you imagine if google docs, sheets, etc all had distinct permissions systems)
Yeah even further, does that mean that SAAS like S3 shouldn't exist because it has multiple users?
I guess one possible solve would be to separate shared services into separate private deployments. Every upstream service gets its own imagine hosting service. Updates can roll out independently. I guess that would solve the blast radius/single source of failure problems but that seems really extreme.
The trick is to have your gateway handle authn, and then proxy authz data upstream so those services can decide how to handle it without needing to make a second call to the identity service.
You probably want to have a UI for account creation and password resets, right? There's a frontend that has to talk directly to identity service.
You may want to bill based on # of active users - well that's interactive with the identity service (you can do this without billing calling the identity services' API, but the alternatives are just other common dependencies.
You may want a tool for the support team to search identity service to find a user or their account status.
If you have a sharing feature, you may want that to verify you are sharing with an account that exists.
The way I've set these things up, nothing talks directly to the identity service. The ID service is a backend behind your gateway like any other service and any UI would have to have the request proxied through the gateway to reach it. Now, you can carve out certain rules (if you control the gateway) where requests headed to /users/* don't require the same authN steps other requests do because it's already headed to the ID server. Internal UIs may or may not work the same, that's really up to you - they won't likely be super high scale. Often the support teams won't even be querying the real DB, but instead a view or copy so they can't affect real user data. A share code for users A->B would just be a request from the UI to the ID server via the gateway, authenticated as User A, and responding with the code for B if possible. Or, I've do it where you could have special logic in the gateway to query 2 servers and combine the responses. No need for services to make requests sideways. Hope that makes sense.
I agree with you. Its interesting when I look at the examples you provide, that they are all non-domain services, so perhaps that is what codifies a potential rule.
You absolutely want the same identity service behind all of your services that rely on an identity concept (and no, you can't just say a gateway should be the only thing talking to an identity service - there are real downstream uses cases such as when identity gets managed).
Similarly there's no reason to have multiple image hosting services. It's fine for two different frontends to use the same one. (And don't just say image hosting should be done in the cloud --- that's just a microservice running elsewhere)
Same for audit logging, outbound email or webhooks, acl systems (can you imagine if google docs, sheets, etc all had distinct permissions systems)