|
|
|
|
|
by jakemoshenko
1715 days ago
|
|
There are a variety of synchronization methods, and the choice of which is very application specific. The simplest choice to get started with is to add it directly to your application logic. The main pro of this solution is that you can directly handle the semantics of when and how to add/remove permissions. For example, it's sometimes safe and idempotent to write permissions for data that may fail to commit, because permissions for the data will never be queried in the future. You can also directly control the management of ZedTokens and effectively eliminate the new enemy problem[0]. As far as I know, this is how Zanzibar is used within Google. Solutions which tail a primary source of truth, such as the database logs, kafka topic, event queue, etc. may perform better in some applications where eventual consistency on permissions is ok. With these systems you are adding some delay in between writing the data and the permissions, which can open you up to new enemy or require UX compensation like adding data on the client side and hoping the permissions replicate before they are ever queried for real. We will work to write a guide that talks about some of these architectures and their pros and cons. [0] https://authzed.com/blog/new-enemies/ |
|