"Can I [action]?" is the exact question that Zanzibar[0] was designed to answer in a highly performant and scalable way.
With multiple data sources reading and writing to SpiceDB [1] (our OSS implementation of Zanzibar), those questions can further be extended into "Can [subject] [action] on [resource]", which allows for supporting not just permissions, but (as you suggested) feature flags, entitlements, role-based access control and even billing-based entitlements (if the billing system's information is supplied in as relationships or dynamically via caveat context [2]).
As a concrete example, feature flags can be represented as a straightforward permission:
definition user {}
definition featureflag {
relation enabled: user
permission is_enabled = enabled
}
They can then be checked directly:
check featureflag:somefeature is_enabled user:{currentuserid}
The real power comes into play when different aspects of the system are combined, such as only allowing a feature flag to be enabled if, say, the user also has another permission:
definition organization {
relation member: user
}
definition featureflag {
relation enabled: user
relation org: organization
permission is_enabled = enabled & org->member
}
In the above example [3], a feature flag is only enabled for the specific user if they were granted the flag
and they are a member of the organization for which the flag was created. While this is somewhat of a constructed example, it demonstrates how combining the models can be used to grant more capabilities.
With caveats [2], these kinds of questions can even depend on dynamic data, such as the time of day, whether the user's account balance is positive, or even be random based on some distribution (to enabled, for example, partial enablement of feature flags)
[0]: https://zanzibar.tech/
[1]: https://spicedb.io
[2]: https://authzed.com/docs/spicedb/concepts/caveats
[3]: https://play.authzed.com/s/eML6cLz9ByAZ/schema
Disclaimer: I'm CTO and a cofounder at AuthZed, and we build SpiceDB