Access control in a media service starts with more than token validation. The real question is whether this user may open this exact object right now, with this subscription, region, device, and role context.
The chapter breaks down how rights are stored and evaluated, how policy interacts with short-lived links and caches, and how access can be revoked without a long window of incorrect decisions.
For interviews and engineering discussions, this case is useful because it quickly brings the conversation to PDP and PEP boundaries, hot-path latency, and the system's ability to explain and log every decision.
Entitlements
The core question is not the token alone, but how quickly and unambiguously the system can determine whether a user may access one exact object under subscription, region, and role constraints.
Policy Versions
Policies change more often than teams expect, which is why the system needs a safe way to publish new rules without long windows of stale cached decisions.
Revocation
Compromised access cannot be disabled node by node by hand: you need a short and reliable propagation path for revocation across the whole stack.
Audit Trail
Support, investigations, and compliance all depend on reconstructing not just the verdict, but also the rule, policy version, and request context behind it.
Acing SDI
Practice task from chapter 16
Authorization for media products with a focus on policy modeling, enforcement points, audit, and reliability.
Access Control for Media App is about designing a dedicated authorization layer that evaluates content entitlements quickly, keeps decisions explainable, and preserves predictable latency on the hot read path. Interviewers look for clear PDP/PEP boundaries, reliable revocation, and safe failure behavior.
Where this pattern matters
- Netflix / Spotify: content access varies by region, subscription plan, and playback rights.
- YouTube Studio: creator teams need different permissions for publishing, deleting, and managing media.
- B2B media SaaS: tenant isolation and auditability are essential for enterprise customers.
- Internal platform tools: operators and services need explicitly controlled access to sensitive actions.
Functional requirements
Core access-control API
POST /authorize- access verdict and reason codePOST /explain- explanation of the rules that were appliedPOST /revoke- emergency revocation of rights or token scopeGET /audit- history lookup bydecision_id
Policy capabilities
- RBAC as the baseline layer, with ABAC and ReBAC for request context and ownership graphs
- Versioned policies with a safe rollout path
- Deny by default for sensitive actions
- A full history of who got access, to what, when, and under which rule
Non-functional requirements
| Requirement | Target | Why it matters |
|---|---|---|
| Decision latency (p95) | < 20ms | Authorization must not become the bottleneck of the API path. |
| Availability | 99.99% | A broken authorization layer blocks critical user actions. |
| Revocation lag | < 5 sec | Compromised access must be shut down quickly. |
| Audit integrity | Immutable log | Incident investigation and compliance reviews depend on it. |
| Tenant isolation | Strict boundary | Prevents cross-tenant leaks and accidental privilege inheritance. |
The core trade-off is keeping user-facing latency low without creating windows where the system still relies on stale access rules.
High-Level Architecture
Theory
ACL/RBAC/ABAC/ReBAC
Access-control models and how to apply them in distributed systems.
High-Level Architecture
decision path, policy stores, audit log, and revocation loopThis topology separates decision evaluation from policy updates and the audit and revocation loop.
This layout keeps the hot decision path separate from the policy control plane, where policy publication, version management, and operational actions live. Media systems also often issue short-lived signed URLs, but the correctness of that access still depends on precise cache invalidation and clean PDP/PEP sync.
Write/Read Paths
Write/Read Paths
How policy changes enter the control plane and how the hot authorization path is served.
Policy changes and revocation signals are written into the versioned store, after which decision caches are synchronized and audit events are emitted.
Policy Change
Layer 1admin/update request
Security/admin service sends policy updates, role grants, and revoke events.
Policy Store
Layer 2versioned write
The update is committed as a new policy version and passes release-time validation.
Invalidate Cache
Layer 3PEP/PDP sync
Invalidation propagates to decision caches and enforcement points.
Audit Stream
Layer 4immutable events
Policy and revoke events are persisted into immutable audit log/SIEM.
Enforcement Ready
Layer 5new rules active
PEP/PDP runs on the new policy version and applies updated decisions.
Write path checkpoints
- •Every policy change must be versioned and attributed to an actor for auditability.
- •Decision caches must be invalidated before the new rules are considered fully active.
- •The revocation path should propagate quickly and block compromised sessions.
Policy consistency and failure handling
Further reading
Identification, Authentication, Authorization
Boundaries between authentication and authorization, token lifecycle, and practical security patterns.
The worst mistake here is granting access after the right should already be gone. The system therefore needs fast revocation, clearly defined fail-closed versus fail-open behavior, and a staged rollout path for policy changes.
Version-aware decision model
Each decision should be tied to both the request context and the exact policy version:
decision = evaluate(subject, resource, action, context, policy_version) cache_key = request_hash + policy_version
- Policy version keeps the decision cache from serving stale answers.
- Reason code lets support and incident responders explain why access was granted or denied.
- Deterministic evaluation makes the same request reproducible during investigation.
Safety controls
- Critical blocking behavior: sensitive actions must not slip through when PDP is unavailable.
- Emergency revocation: active sessions and tokens need to be shut down without a long inconsistency window.
- Anomaly detection: spikes in denials and unusual access patterns should page the team quickly.
- Rollout guards: canaries and automatic rollback stop a bad policy from breaking access at scale.
Risks and common mistakes
- Mixed authentication and authorization concerns: blurred boundaries make bypasses much easier.
- Stale decision cache: policy changes are correct in storage but not on the serving path.
- No explainability path: support cannot show why access was denied.
- Slow revocation: a compromised account keeps access for too long.
- Hidden privilege escalation: the wrong combination of roles, tenants, and contextual rules silently grants extra rights.
What to cover in the interview
- Why this domain needs a specific mix of RBAC, ABAC, and ReBAC.
- How the system eliminates stale decisions after policy changes.
- Where a softer degraded mode is acceptable and where access must be blocked immediately.
- Which metrics and logs let the team explain denials and investigate incidents.
Related chapters
- Identification, authentication, authorization - Boundaries between authentication and authorization, token lifecycle, and baseline identity patterns.
- ACL/RBAC/ABAC/ReBAC - How to choose an access-control model for roles, request context, and ownership graphs.
- API Security Patterns - Gateway- and service-level enforcement patterns that reduce the risk of bypassing access checks.
- Zero Trust - Least-privilege design, continuous verification, and trust segmentation for distributed access paths.
- SRE Book - Reliability practices and operational guardrails for critical access-control services.
- Payment System - Parallels around auditability, safe failure behavior, and revocation in sensitive systems.