Design a Role-Based Access Control System With Fast Checks and Bounded Revocation

In a senior software engineer loop whose rounds mixed coding with design discussion, held in conversation and a shared editor rather than with a diagramming tool, you are asked to design a role-based access control (RBAC) system. Describe the components, data structures and interfaces in words and short code sketches. Unless the interviewer narrows it, assume the usual RBAC scope: - A permission is an action on a type of resource, such as reading or editing documents. - A role is a named set of permissions. Principals (users, and possibly groups or service accounts) are assigned roles. - Applications ask one question on protected requests: may this principal perform this action on this resource? - Administrators create and change roles and assign or remove them, and those changes must take effect, including revocations. ### Clarifying Questions - Are role assignments global, or scoped to a tenant, a project or an individual resource? - Can roles inherit from other roles, and are explicit deny rules needed or is the model allow-only? - Is this a library inside one application or a shared authorization service used by many services? - How quickly must a revoked permission stop being honored, and roughly how many checks happen per administrative change? - Is an audit trail of changes and of denied requests required? ### Part 1 — Model roles and answer a permission check Define the core entities and how they relate, the administrative operations, and the check operation that applications call. Sketch the data structures that let a check be answered quickly, and explain how a check is evaluated, including role inheritance if your model has it. ```hint Work backward from the check Start from the exact question an application asks at request time, then decide what must be stored, and in what shape, to answer it without walking every role. ``` #### What This Part Should Cover - Entities and relationships: principals, roles, permissions, assignments and their scope - Administrative operations and a check API with clear inputs and outputs - Evaluation rules, including inheritance, scope matching and the default decision - The cost of a single check and what keeps it cheap ### Part 2 — Make checks fast without breaking revocation Checks sit on the request path of many services, while administrative changes are comparatively rare. Explain how you would serve checks with low latency and high availability, how a change reaches every place that evaluates permissions, and how long a revoked permission can still be honored. Cover what happens when the authorization component is slow or unavailable. ```hint Where does the cache live Caching is the obvious first move; the real design question is where the cached data sits and what event or deadline forces it to be discarded. ``` #### What This Part Should Cover - The read path and where permission data is cached - How changes propagate, and the resulting worst-case delay for a revocation - Behavior on failure, decided explicitly per kind of permission - Audit records and the metrics that show the system is healthy ### What a Strong Answer Covers - Settles scoping, inheritance and deny semantics before fixing the data model - Denies by default and keeps the model simple enough to audit - States the freshness-versus-latency trade-off and a concrete bound on stale permissions - Protects the integrity of the role model itself: cycle checks, safe deletion and tenant isolation - Treats the system as shared infrastructure: debuggability, observability and recovery from bad administrative changes ### Follow-up Questions - How would you support a rule such as "only a document's owner may delete it" without creating a role per document? - An administrator accidentally removes a role that thousands of users depend on. How do you detect it and recover? - How would you let an engineer find out why a request was denied, without exposing permission data to end users? - How would you verify that a refactor of the role definitions did not change anyone's effective permissions?