Scale an Authorization Checker

# Scale an Authorization Checker Extend a role-based authorization checker for concurrent and distributed use. A decision follows deny-overrides-allow semantics, and missing permission means deny. Explain how permission updates become visible, how readers remain fast, and how the system avoids temporarily granting access that should be denied. ### Constraints & Assumptions - Many application instances may evaluate permissions concurrently. - Roles and permissions change less often than they are read. - Revoking access is more safety-critical than briefly delaying a new grant. ### Clarifying Questions to Ask - What revocation-latency guarantee is required? - Must decisions be globally consistent, or may some grants be briefly stale? - How are users, roles, and properties partitioned, and what audit evidence is required? ```hint Treat revocation as a distinct risk A cache policy that is acceptable for a new allow may be unsafe for a new deny. ``` ### What a Strong Answer Covers - A canonical policy store and versioned updates. - Thread-safe local evaluation and cache invalidation. - Fail-closed behavior during missing, stale, or unreachable state. - Audit logs, rollout strategy, and consistency trade-offs. ### Follow-up Questions - How would you roll back a bad policy update? - What happens when an authorization dependency is unavailable?