Usually in a web app you have some type of group system which determines permissions on a variety of resources. Like github orgs, slack workspaces, etc.

As an example, let's call this group system in our app "teams". Let's also say that a user can create files/folders for the team if and only if they are a member of that team.

So, you could naively say that "teams" is its own service, and "files" is also its own service. But the files service will need to permit users access to resources based on membership to the team. How do you resolve that permission?

1. Actually make them a single service. This would work to start, but what if you have a bunch of other features with the same derived permission requirement? You'll end up with a monolith.

2. Services do on demand calls to the team service for the user's membership (this introduces a hard dependency!).

3. Bake team membership into the JWT (this means that JWTs operate as a cache, causing issues when someone is added or removed from a team, it also leads to token bloat).

4. Have a permissions service which supports simple ACLs. Team service registers permissions here and others read from it. This offers logical separation of concerns, but not operational (since all services now have a hard dependency on the permissions service)

5. A pub/sub system that listens to team changes and propagates them to ACLs in other services. But this doesn't work in the case of preventing a user from creating a new file for a team they are not a member, since you need to resolve the permission at that instant they make that request.

6. Add an aggregation API (or saga if you wanted to use messaging) which orchestrates the creation of files by calling the teams service for membership, and then the files service if the creator is a member of the team. This requires additional infrastructure, and in the case of messaging makes the operation asynchronous.

Are there any options I missed here? Which do you prefer?