Design an ACL authorization checking service

Design a centralized authorization (ACL) checking service used by other internal services to decide whether a principal can perform an action on a resource.

Context

Multiple microservices (e.g., Orders, Docs, Billing) need consistent access control. Instead of each service implementing authorization logic, they call an internal service to evaluate policies.

Requirements

Core functionality

• Provide a decision API: given (principal, action, resource, context) return ALLOW/DENY .
• Support common ACL semantics:
  • Principals: users and service accounts.
  • Resources: hierarchical resources (e.g., /orgs/{id}/projects/{id}/docs/{id} ) and non-hierarchical resources.
  • Actions: read , write , delete , admin , etc.
  • Groups/roles (optional) and explicit per-resource grants.
  • Default deny; explicit deny should override allow (if you choose to support denies).
• Policy management:
  • Create/update/delete policies and group memberships.
  • Changes should propagate to authorization decisions quickly.

Non-functional (make reasonable assumptions and state them)

• Low latency for checks (e.g., single-digit ms p99 inside a region).
• High availability (e.g., 99.99%+).
• High read-to-write ratio (checks are frequent; policy updates are relatively infrequent).
• Multi-tenant support and isolation.
• Strong security (authn/authz for callers, auditability).

Deliverables

• High-level architecture and main components.
• API design (check + management APIs).
• Data model for ACLs/roles/groups.
• Caching strategy and consistency/invalidation approach.
• Handling scale, multi-region, failure modes, and security.
• Observability: key metrics and logs/audit trails.