A file collaboration platform must decide how to model data access across personal files, shared folders, team spaces and external sharing. Which model fits?

Why role-based breaks here

Roles describe what a kind of user can do. This domain's question is "can this specific user access this specific object", and the answer depends on a chain of relationships: the user is in a group, the group has access to a folder, the file is in a subfolder, and someone shared a link with an external party.

Modelling that with roles produces a role per sharing situation — role explosion, where the role count grows with the object count and nobody can answer who has access to what.

Why per-file lists break too

ACLs answer the question but do not inherit. Moving a folder means rewriting the lists of everything inside it, which is expensive and non-atomic — and permission changes that are not atomic produce windows where access is wrong in one direction or the other.

What relationship-based gives

• Inheritance through the object graph, so a folder's permission applies to its contents without duplication.
• Answers to both directions: what can this user see, and who can see this object. The second question is what audits and incident response actually need, and it is the one most models answer badly.
• Group and team membership as edges, so organisational change propagates naturally.

The engineering constraints

Authorisation is on every request, so it must be single-digit milliseconds. That means a purpose-built store, aggressive caching, and a deliberate decision about staleness on revocation — how long a removed permission may still be honoured. Caching permissions is necessary and it directly trades latency against the revocation window, which is a security decision that should be made explicitly and stated.