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 lives on the hot read path: every playback hits an access check, and that check can be neither slow nor sloppy. The layer has to return content entitlements quickly, keep each verdict explainable, and hold latency predictable. Interviewers look at the boundary between the decision point and the enforcement point, at how fast revocation propagates, and at what the system does under load spikes and failures — whether it keeps handing out access by inertia.
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 reach into sensitive actions — without explicit rules and an audit trail, that access can be neither contained nor investigated.
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 opening a window where the system still relies on stale access rules. The more aggressively you cache decisions, the longer old verdicts survive after a policy change.
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 loopRequest plane
Policy and data plane
Audit and control plane
This 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: Security/admin service sends policy updates, role grants, and revoke events.
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.
References
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.