#Hi, can someone help me to understand

1 messages · Page 1 of 1 (latest)

unkempt prawn
#

Hi @proper anvil in Permify, a snapshot is an encoded timestamp used to ensure that access control checks return fresh results. The creation of a snapshot occurs when writing data through the API, such as when a relational tuple is written. This process generates a Snap Token which is then associated with the resource to ensure that any access control checks performed are as up-to-date as the last write operation.

Regarding the concern of high traffic hitting the service before the snapshot is ready. If a snap token is not provided during a request, Permify retrieves the ID of the latest transaction from its 'transactions' table, which represents the most current snapshot of the database. This ID is then used for the query, and the results are cached using this ID. When subsequent identical requests are made without specifying a Snap Token, they will utilize the latest transaction ID, ensuring that they reflect the most recent state of the database.

#

Hope that's helpful.

proper anvil
#

Thanks @unkempt prawn for your explanation. I'm still a bit fuzzy about the relationship between cache and snapshots, and the performance implications. Do we cache the whole snapshot associated with the TxID? or do we cache each relationships? Does it mean for checks with snapToken, the whole snapshot and all the whole cache is stale once we make a single write?

proper anvil
#

One more question on consistency - say we have permission relationship of doc -> group -> subgroup -> member. i.e. subgroup X members have access to doc Y. When we add a member to the subgroup (a Write), we get a new SnapToken. But without knowing the policy, how would we know to update the SnapToken for the doc Y?

unkempt prawn
#

Hi @proper anvil

#

Our way of caching and handling snapshots is designed to optimize both performance and consistency actually.

#

So regarding caching, permify does not cache the entire snapshot associated with a TxID. Instead, it caches the results of access control checks. These results are tied to specific snapshots through the use of snap tokens, ensuring that the data remains consistent and fresh. This mechanism involves caching individual access check results rather than the entire snapshot of the database state at a given time.

#

When a write operation occurs, a new Snap Token is generated, which represents a snapshot of the database at that moment. Subsequent access control checks can use this Snap Token to ensure they are referencing a fresh and consistent view of the database. However, the whole cache does not become stale with a single write operation. Only the cached entries directly affected by the write would need to be invalidated or updated.

The key point here is that the entire cache does not become stale after a single write. The use of Snap Tokens allows Permify to maintain a highly efficient cache by ensuring only the affected parts of the cache are invalidated or updated after a write operation. This allows the rest of the cache, which remains unaffected by the write, to continue serving requests efficiently.

#

One more question on consistency - say we have permission relationship of doc -> group -> subgroup -> member. i.e. subgroup X members have access to doc Y. When we add a member to the subgroup (a Write), we get a new SnapToken. But without knowing the policy, how would we know to update the SnapToken for the doc Y?

#

Actually knowing the specific policy isn't required for the Snap Token to be effective. The Snap Token inherently ensures that any changes, such as adding a member to a subgroup, are accounted for in subsequent authorization checks, thus indirectly updating access for doc Y based on the most recent permission relationships.

#

I tried to explain these things in detail, hope thats make sense

#

Let me know if you have further questions

proper anvil
#

Thank @unkempt prawn I still have questions regarding why "knowing the specific policy isn't required for the Snap Token to be effective". Say a member X is removed from a group as WRITER, and the doc's snapToken is not updated because it's not aware of this transitive relationship change on the group side. So now the cached permissions on the Doc is stale, wouldn't we still give write access to member X for the duration of cache ?

unkempt prawn
#

Ok for the scenario you described, it might indeed lead to a situation where cached permissions could become stale. But the resource's snap token lets say doc:103's snap token for your case, needed to be updated when some associated tuple deleted.