Design an ACL Check Service
Design an access-control service that other services call on their hot path: isAllowed(subject, resource, action). Subjects belong to groups and roles, which nest; grants attach to resources and to hierarchies of resources.
The callers care about latency above everything, and about never granting access that was revoked. Cover the source of truth, how a check is answered quickly, how a change to a grant or a group becomes visible, what happens when the store is unreachable, and how every decision can be audited later.
Hints
Hint 1
Keep grants and memberships in a durable store, but answer checks from a cache of compiled rules keyed by (subject, resource): the hot path must not walk the hierarchy.
Hint 2
Change events invalidate affected cache entries; the trade-off is flattening the group and role closure at write time (fast reads, slow invalidation) versus walking the hierarchy per read.
Hint 3
When the store is unreachable, fail closed and say why: a false allow is a security incident, a false deny is an outage with a clear cause.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.