A few years ago I tried implementing Zanzibar for my company, but I needed one change - I don't want to store permissions in Zanzibar but instead it should act as an API gateway that lookup permissions stored in the services. Like if user act on an order, the user service and order service should be contacted.<p>Turns out it is pretty much required for a distributed system. A common question in microservice architecture is whether to validate permissions only at the API gateway layer, or at every points of use. If you want to validate it everywhere, what happen when you're running async job and the user get revoked. In Zanzibar you attach the cookie as the user's context and Zanzibar will always return the same answer. (This is not meant for cronjob where user set it once and it repeat daily, but rather for quick, one off background jobs like generating reports to users' email) If you remove the internal store, the application's API must provide point-in-time query, which I never see one application does that let alone a microservice environment.<p>Another problem is cache invalidation - when permission get added or removed, users want that to reflect quickly. I can't remember how the paper handle this, but in any case since the permissions are stored in Zanzibar, every changes goes through Zanzibar. If you remove the internal data store, you lose the change notification.<p>The pseudo-Zanzibar lives in production today, but I feel like it is one of the mistake in my career.