An AuthN/Z system would probably end looking like counterexample #2, which immediately raised a red flag for me about the article.

▲

Alupis 3 days ago | parent | next [-]

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).

▲

davewritescode 3 days ago | parent | prev | next [-]

There’s a million reasonable situations where this pattern could arise because of you want to encapsulate a domain behind a micro service.

Take the simplest case of a CRM system a service provides search/segmentation and CRUD on top of customer lists. I can think of a million ways other services could use that data.

▲

3 days ago | parent | prev | next [-]

[deleted]

▲

waterproof 3 days ago | parent | prev [-]

Yeah if services can't be used by multiple other services, then what's the point?

▲

mon_ 3 days ago | parent | next [-]

The article doesn't make that claim. For example, the service n7 is used by multiple other nodes, namely n3 and n4. There is no cycle there, so it's okay.

	▲	PunchyHamster 3 days ago \| parent [-]
		but why is having multiple paths to a service wrong ? The article just claims "it does bad things", without explaining how it does bad things and why it would be bad in that context.

▲

spyspy 3 days ago | parent | prev [-]

Treating N4 as a service is fair. I think the article was leaning more toward that idea of N4 being a database, which is a legit bad idea with microservices (if fact defeating the point entirely). My takeaway is that if you're going to have a service that many other services depend on, you can do it but you need to be highly away of that brittleness. Your N4 service needs to be bulletproof. Netflix ran into this exact issue with their distributed cache.