Dispatch is the computation and routing layer that decomposes permission checks, fans out sub-requests, and uses cache-aware execution to answer authorization questions. Datastore access is the persistence layer that stores relationship and schema data with the ordering guarantees needed for correctness. One computes and coordinates, while the other durably stores the authoritative inputs.
Why This Matters for Security Teams
Dispatch and datastore access often sit on opposite sides of an authorization system, but teams blur them when they treat every failure as a generic “auth check problem.” That mistake hides whether the issue is orchestration, consistency, schema evolution, or the backing store itself. In a Zanzibar-style architecture, those concerns lead to different fixes, different scaling limits, and different failure domains. The distinction matters most when teams are debugging stale answers, unexpected denials, or latency spikes.
Security teams also need the split because the datastore is part of the trust boundary, while dispatch is part of the execution path. If the system answers incorrectly, the root cause may be a coordination bug in dispatch even when the relationships in storage are correct. If the stored tuples or schema are wrong, dispatch can only produce a fast, wrong answer. In practice, many production incidents are misdiagnosed because responders look at the authorization result first instead of asking which layer actually lost correctness.
How It Works in Practice
Dispatch is the layer that turns a user’s authorization query into a graph traversal. It decomposes the check into sub-requests, decides what can be reused from cache, orders the fan-out, and merges results back into a final allow or deny. Its job is to move quickly and correctly across relationships, but it does not own the authoritative state. It is closer to a computation scheduler than a database reader.
Datastore access is different. It is responsible for persisting the relationship tuples, namespace definitions, caveats, and schema data that dispatch needs to reason over. In Zanzibar-style systems, the datastore must preserve the ordering and consistency properties that make authorization results trustworthy. If dispatch reads data too early, or from the wrong point in the write sequence, it can compute against a partial view and return the wrong answer even if the underlying design is sound.
- Dispatch answers “what needs to be checked next?” and “can this be short-circuited?”
- Datastore access answers “what is the authoritative relationship state?” and “at what version is it safe to read?”
- Dispatch is optimized for execution latency, datastore access for correctness and durability.
- Dispatch can cache and reuse sub-results, but it cannot invent missing authoritative data.
The practical boundary is that dispatch may tolerate temporary computation inefficiency, while datastore access cannot tolerate ambiguity about committed state. That is why datastore design usually emphasizes versioning, transactional ordering, and read-your-writes style guarantees. When those guarantees weaken, dispatch can amplify the problem by spreading one inconsistent read across many sub-checks.
For teams using a Zanzibar-like model, the best mental model is that dispatch computes over relationship data, while datastore access governs the integrity of the data being computed over. These controls tend to break down when the datastore is eventually consistent across replicas and dispatch assumes the latest relationship graph is already visible.
Common Variations and Edge Cases
Tighter datastore guarantees often increase write-path complexity and can raise latency, so teams have to balance freshness against throughput. The tradeoff is not always symmetric: a slightly slower dispatch path is usually acceptable, but a weaker datastore consistency model can create authorization errors that are hard to detect and harder to prove after the fact.
One common edge case is cached authorization state. Dispatch may cache intermediate results to reduce repeated graph walks, but those caches must be invalidated or scoped carefully when relationship data changes. Another is schema migration: dispatch can usually adapt to new evaluation logic, but datastore access must ensure old and new representations are not mixed in a way that changes meaning. A third is multi-region deployment, where dispatch can be globally distributed while datastore access still needs a clear source of truth for committed updates.
Current guidance suggests treating any optimization that weakens read freshness or ordering guarantees as a correctness risk first and a performance win second. The question is not whether dispatch can run faster, but whether the stored relationship state remains authoritative enough for authorization decisions to be defensible.
In large deployments, the sharpest failures usually appear when a cache, replica, or migration path makes dispatch see a plausible but incomplete graph.
Risk and Threat Considerations
The main risk is authorization drift, where dispatch computes against stale, partial, or mismatched relationship state and produces the wrong allow or deny. That can create over-authorization, denial of service, or audit confusion even when the intended policy is correct.
Failure mechanism: The failure usually comes from inconsistent reads, cache staleness, replica lag, or incorrect version ordering. An attacker does not need to break the model itself if they can exploit a window where dispatch sees outdated relationship data or the datastore exposes an incomplete commit sequence.
Impact: The system can grant access that should have been denied, block legitimate users, or produce irreproducible authorization results that complicate incident response and policy verification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Control | Dispatch and datastore separation affects access decision integrity. |
| Recommendation — Enforce access decisions against authoritative state and prevent stale reads from driving authorization. | ||
| CIS Controls v8 | 6 — Access Control Management | The topic centers on correct authorization paths and controlled access enforcement. |
| Recommendation — Limit authorization paths to trusted data sources and review consistency assumptions regularly. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Authorization checks must enforce policy using correct relationship state. |
| AU-2 — Event Logging | Split-layer authorization failures need traceable decision and datastore events. | |
| Recommendation — Validate that enforcement uses authoritative relationships and rejects partial or stale inputs. Log dispatch decisions and datastore version events for later reconstruction and audit. | ||
| NIST Zero Trust (SP 800-207) | PE — Policy Enforcement Point | Dispatch functions like a policy enforcement and evaluation path in ZTA terms. |
| Recommendation — Separate policy decision logic from data storage and preserve strong trust boundaries. | ||
Practitioner Guidance
What to verify: Verify that dispatch never treats a relationship graph as authoritative unless the datastore has provided the versioning and ordering guarantees required by the evaluation model. If the system supports replication, confirm that the read path cannot bypass the freshness boundary for security-sensitive checks.
Decision rule: If the failure involves stale or inconsistent authorization outcomes, investigate datastore consistency, commit visibility, and replica lag first. If the failure involves excessive fan-out, poor caching, or slow graph traversal with correct stored data, focus on dispatch. Do not collapse those into one remediation bucket.
Practitioner takeaway: The security question is not just whether the answer is right, but whether the right answer came from the correct layer, with the correct version of truth, at the moment the decision was made.
