[gneray]

Agreed! But you're glossing over the Zanzibar point of view on this topic, which falls back to dual-writes. That approach has a lot of downsides: "Unfortunately, when making writes to multiple systems, there are no easy answers."[0]

Having spoken with the actual creators of Zanzibar, they lament the massive challenge this design presents and the heroics they undertook over 7+ years at Google to overcome them.

By contrast, we're seeing lots of the best tech companies opt for approaches that let them leave the data in their source database wherever and as much as possible [1]

[0] https://authzed.com/blog/the-dual-write-problem

[1] https://www.osohq.com/post/local-authorization

I'm founder of Oso btw.

[hardbyte]

Yeah a big motivation for us was avoiding the need to keep another system up to date. Gatehouse basically sits at the execute policy layer, and we let the application code decide how to unify the data (or not).

Oso local authorization looks like a fantastic solution.

[jzelinskie]

Thanks for the response. In my opinion, oso does the best of job of any policy engine at prescribing how input data to their system is fed (and your linked blog demonstrates it well!).

I do think you might have pivoted the conversation, though. My post was purely about federation strategies and policy engines, but you appear to discussing consistency and Zanzibar, which is only tangentially related. Federation and consistency aren't necessarily coupled. Oso also would require a complex scheme for achieving strict serializability, but it instead chooses to trade-off consistency of the centralized data in favor for the local data.