RBAC / ABAC Policy Engine #

This note models an RBAC/ABAC policy engine where callers ask whether a subject may perform an action on a resource, admins update roles, bindings, attributes, and policies, and the system evaluates decisions consistently at scale.

Step 1 - Normalize #

Assume the baseline prompt is:

• design an RBAC / ABAC policy engine
• callers ask authorization questions like can user U do action A on resource R
• policies can reference roles, bindings, subject/resource attributes, and contextual attributes
• admins update policies and role bindings over time
• policy evaluation must be fast and correct across many services and tenants

Normalize into state-affecting paths.

Notes on normalization #

Important choices:

• authorization evaluation is a hot read path
• policy and role definitions are current-value control state
• role grants/revokes are lifecycle transitions
• attribute updates are current-value state
• snapshot generation/propagation is explicit because evaluators usually should not hit the control plane on every request

This system is a hybrid of:

• policy and relationship state
• hot-path evaluation
• control plane to evaluator snapshot distribution

Step 2 - Critical Path Selection #

Baseline critical paths #

Main C1 paths:

• P1 evaluate authorization
• P2 update policy
• P3 update role definition
• P4 grant/revoke binding
• P5 update subject attributes
• P6 update resource attributes
• P7 compute policy snapshot
• P8 propagate evaluator snapshot
• P9 route to shard owner
• P10 reassign shard ownership

This design is driven by:

• authoritative current policy, bindings, and attributes
• fast evaluator reads
• bounded-stale but monotonic config distribution

Step 3 - Primary State Extraction #

For an RBAC/ABAC engine, the minimal primary state is policy definitions, role definitions, role-binding lifecycle, subject/resource attributes, derived policy snapshot state, and routing/ownership state.

Important modeling choices #

PolicyState #

Primary because:

• policy language/rules are authoritative control truth

RoleBindingState #

Primary because:

• grants and revokes are not just facts; current active/inactive lifecycle matters

SubjectAttributeState / ResourceAttributeState #

Primary because:

• ABAC decisions depend on current attributes

PolicySnapshot #

Primary because:

• many production engines derive an effective evaluation model from raw policies, roles, and bindings

EvaluatorConfigSnapshot #

Kept explicit because:

• hot-path evaluators often run from local snapshots, not synchronous control-plane reads

Minimal strict primary set #

The strongest minimal set is:

• PolicyState
• RoleDefinition
• RoleBindingState
• SubjectAttributeState
• ResourceAttributeState
• PolicySnapshot
• EvaluatorConfigSnapshot
• PartitionOwnership
• PartitionMap

Step 4 - Hard Invariants #

For an RBAC/ABAC policy engine, the hard invariants are about one authoritative current policy/binding/attribute state, correct derived snapshots, and authorization decisions being evaluated against the intended current version.

What matters most #

1. One authoritative current binding state #

Role grants and revokes must not race into conflicting current truth.

2. Snapshot correctness #

Evaluators can be local and fast, but their snapshot must correspond to real policy truth.

3. Monotonic evaluator config #

An evaluator must not move backward to an older policy version.

4. Freshness is a deliberate tradeoff #

If bounded-stale local evaluation is allowed, that must be explicit.

Step 5 - Execution Context #

For the baseline RBAC/ABAC policy engine:

Derived implications #

• holder_may_crash = false

  • evaluators can fail, but they do not hold mutable business ownership like queue workers

• cross_service_write = false

  • baseline keeps policy, bindings, attributes, and snapshots in one logical service

• bounded_staleness_allowed = true

  • hot-path local evaluation can tolerate bounded lag if explicit

• cross_service_atomicity_required = false

  • no multi-service transaction across unrelated services in baseline

• exclusive_claim_required = true

  • shard ownership must be exclusive

• guarded_by_current_state = true

  • binding grants/revokes and snapshot updates depend on current state

What this implies #

This pushes us toward:

• one authoritative owner per tenant/policy shard
• current-value policy and attribute state
• local evaluator snapshots distributed from control plane
• monotonic versioned evaluation

Step 6 - Deterministic Mechanism Selection #

Why these fit #

Policies, roles, and attributes #

These are current-value control state, so overwrite fits.

Role bindings #

Bindings have lifecycle and current-state transitions, so guarded transition fits.

Snapshot build and propagation #

These are derived current views published to evaluators, so overwrite fits.

Routing #

One owner per shard is required for correctness of authoritative updates, so exclusive claim fits.

Canonical substrate implied #

The baseline now points to:

• sharded policy-control service
• one owner per tenant or policy shard
• current policy, binding, and attribute state
• derived snapshots pushed to evaluators
• bounded-stale but monotonic local decisions

Step 7 - Read Model / Source of Truth #

For an RBAC/ABAC engine, truth is mostly direct source state plus derived evaluator snapshots. Audit views are derived.

Important point #

For the core semantics:

• authoritative truth lives in policy, binding, and attribute state
• evaluators usually read local snapshots for the hot path
• audit views are projections

Step 8 - Failure Handling #

What matters most #

1. Snapshot monotonicity #

Evaluators must not accept older config after newer config is installed.

2. Freshness versus latency #

The main architectural tradeoff is:

• direct source read for every authorization
• versus local snapshot with bounded lag

3. Binding lifecycle correctness #

Revokes must not be lost behind stale grants.

4. Decision logs are optional for correctness #

Audit logging matters for compliance, but decision correctness depends first on policy truth and evaluator freshness.

Step 9 - Scale Adjustments #

What scales well #

This system scales by:

• sharding policy truth by tenant/scope
• evaluating from local snapshots
• limiting dynamic attribute fetches on the hot path
• incrementally recomputing only affected policy scopes

What fails first #

Usually:

• very large binding graphs
• high-frequency policy churn
• attribute fetches embedded in every auth decision
• overly broad global snapshots

Canonical design conclusion #

The mechanical outcome is:

• primary state:
  • PolicyState
  • RoleDefinition
  • RoleBindingState
  • SubjectAttributeState
  • ResourceAttributeState
  • PolicySnapshot
  • EvaluatorConfigSnapshot
  • PartitionOwnership
  • PartitionMap
• critical invariants:
  • one authoritative current policy/binding/attribute state
  • correct derived snapshots for evaluator scopes
  • monotonic evaluator config propagation
  • authorization decisions evaluated against intended snapshot/source version
  • exclusive shard ownership for policy truth
• mechanisms:
  • overwrite current value for policy/roles/attributes
  • guarded transitions for binding lifecycle
  • snapshot recompute and versioned propagation
  • fenced shard ownership
• reads:
  • hot path from authoritative or approved local snapshot
  • projections for audit and access activity

Polished interview answer #

I’d build the RBAC/ABAC engine as a sharded policy-control service with local evaluator snapshots. The source of truth is current policy definitions, role definitions, role bindings, and subject/resource attributes. Control-plane owners recompute an effective policy snapshot for each tenant or evaluator scope and propagate those snapshots monotonically to evaluators, so the hot authorization path can run in memory without querying the control plane on every request. Grants and revokes are guarded binding-state transitions, while policy and attribute updates are versioned overwrites. The main scaling levers are more tenant shards, incremental snapshot recompute, tight bounds on dynamic attribute lookups, and keeping audit views off the decision hot path.

Concrete Substrate #

I’ll choose a control-plane/data-plane authorization system with authoritative policy shards plus local evaluator snapshots as the concrete baseline, because it matches the mechanics we derived:

• current-value policy, role, binding, and attribute state
• derived policy snapshots
• monotonic snapshot publication to evaluators
• one owner per shard

Concrete tech family:

• control plane in Go or Java
• authoritative state store:
  • replicated DB or RocksDB-backed service state
• metadata/control:
  • etcd or internal metadata quorum for shard ownership/routing
• evaluator sidecars/libraries or central PDP fleet using in-memory snapshots

Each shard owner stores:

• current policies
• current roles and bindings
• current subject/resource attributes
• latest PolicySnapshot per scope

Evaluators store:

• in-memory EvaluatorConfigSnapshot
• optional decision cache keyed by (subject, action, resource, context hash, snapshot version)

Operation Layer #

1. Update role binding #

API

• PutRoleBinding(subject_id, role_id, scope, desired_state, expected_version?)

Initiator

• admin

Entry point

• policy API

Authoritative decider

• shard owner for policy/binding scope

Precondition

• current binding version matches if optimistic concurrency used

Transition

• guarded update of RoleBindingState
• trigger affected snapshot recompute

2. Update policy #

API

• PutPolicy(scope, policy_doc, expected_version?)

Initiator

• admin

Entry point

• policy API

Authoritative decider

• shard owner for policy scope

Precondition

• policy version matches if optimistic concurrency used

Transition

• overwrite PolicyState
• trigger affected snapshot recompute

3. Evaluate authorization #

API

• Authorize(subject, action, resource, context)

Initiator

• client/service

Entry point

• evaluator / PDP

Authoritative decider

• local EvaluatorConfigSnapshot, or authoritative policy shard for strong mode

Precondition

• evaluator snapshot version valid for tenant/scope

Transition

• none on source truth

Response

• {allow|deny, reason, snapshot_version}

4. Recompute snapshot #

API

• internal control-plane recompute flow

Initiator

• system

Entry point

• shard owner

Authoritative decider

• shard owner

Precondition

• source policy/role/binding/attribute state changed

Transition

• recompute PolicySnapshot
• bump version

5. Propagate snapshot #

API

• internal snapshot push/pull

Initiator

• system

Entry point

• control plane / evaluator

Authoritative decider

• control plane snapshot publisher

Precondition

• newer PolicySnapshot version exists

Transition

• overwrite EvaluatorConfigSnapshot

Entry Point vs Decider vs Responder #

Concrete HLD #

Main components:

• policy control-plane API
  • receives policy, role, binding, and attribute updates
• policy shard owners
  • authoritative owners for policy truth and snapshot recompute
• evaluator fleet or sidecars
  • answer hot authorization queries from local snapshots
• metadata/control service
  • tracks shard ownership and routing
• audit/activity pipeline
  • serves decision logs and compliance views

Short Interview Version #

I’d build the RBAC/ABAC engine as a sharded policy-control service with local evaluator snapshots. The source of truth is current policy definitions, role definitions, role bindings, and subject/resource attributes. Control-plane owners recompute an effective policy snapshot for each tenant or evaluator scope and propagate those snapshots monotonically to evaluators, so the hot authorization path can run in memory without querying the control plane on every request. Grants and revokes are guarded binding-state transitions, while policy and attribute updates are versioned overwrites. The main scaling levers are more tenant shards, incremental snapshot recompute, tight bounds on dynamic attribute lookups, and keeping audit views off the decision hot path.