There's no particular reason an Auth system must be designed like counterexample #2. There's many ways to design that system and avoid cycles. You can leverage caching of role information - propagated via messages/bus, JWT's with roles baked-in and IDP's you trust, etc. Hitting an Auth service for every request is chaotic and likely a source of issue.

▲

joshuamorton 3 days ago | parent [-]

You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies.

If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.

	▲	Alupis 3 days ago \| parent [-]
		You shouldn't depend on the auth service, just subscribe to it's messages and/or trust your IDP's tokens. This article, in my interpretation, is about hard dependencies, not soft. Each of your services should have their own view of "the world". If they aren't able to auth/auth a request, it's rejected - as it should be, until they have the required information to accept the request (ie. broadcasted role information and/or an acceptable jwt).