www.icact.org

Member Login

TACT Journal Homepage

Call for Paper

Committee

Find My Paper

Author Homepage

Statistics & History

Welcome Message

Paper Procedure

FAQ

Paper Archives

Outstanding Papers

Program & Proceedings

Presentation Platform

Hotel & Travel Info

Photo Gallery

Scheduler Login

Seminar

Archives Login

Sponsors

Virual Oral Question and Answer


IEEE/ICACT20260076 Question.1 Questioner: abilaaniloshan@gmail.com 2026-02-09 오후 3:36:22	IEEE/ICACT20260076 Answer.1 Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-09 오후 3:36:22
Your index uses a blue–green write queue and may reject queries that require freshness beyond the last index update. In production Zanzibar-like systems, how do you guarantee correctness or strong consistency during high write bursts—especially for permission revocations—without falling back too often to SpiceDB’s BFS resolver?	Auth graphs are empirically read-heavy (~99% checks, ~1% writes), so production designs optimize for fast indexed reads while amortizing write cost. During high write bursts, updates are absorbed into the blue–green write queue, and index recomputation is triggered either when a write-count threshold or time bound is crossed, preventing the index from drifting too far from the datastore state. Queries that require freshness newer than the last index update are not answered by the index and are handed to SpiceDB’s resolver, so correctness—especially for revocations—is preserved even under bursty writes. Because most traffic is reads, this fallback path remains rare, letting the system retain low latency without sacrificing strong authorization guarantees.

Select Voice