Goten Protocol Flows

Design decision includes:

1. services are isolated, but they can use/import services on lower levels only, and they can support only a subset of regions available from these used/imported services.
2. deployments within the Service must be isolated in the context of versioning. Therefore, they don’t need to point to the same primary API version and each Service version may import different services in different versions.
3. references may point across services only if the Service imports another service. References across regions are fine, it is assumed regions for the same Service trust each other, at least for now.
4. all references must carry region, version, and service information to maintain full global env.
5. We have schema and meta owner references. Schema refs define a region by name, version, and service by context. Meta refs have separate fields for region, service, and version.
6. Schema references may be of blocking type, use cascade deletion, or unset.
7. Meta references must trigger cascade deletion if all owners disappear.
8. Each Deployment, Service + Region pair, is responsible for maintaining metadata.syncing fields of resources it owns.
9. Each Deployment is responsible for catching up with read-copies from other regions available for them.
10. Each Deployment is responsible for local database schema and upgrades.
11. Each Deployment is responsible for Meta owner references in all service regions if they point to the Deployment (via Kind and Region fields!).
12. Every time cross-region/service references are established, the other side may reject this relationship.

We have several components in API servers and db controllers for maintaining order in this graph. Points one to three are enforced by Meta service and EnvRegistry components. EnvRegistry uses generated descriptors from the Goten specification to populate the Meta service. If someone is “cheating”, then look at point twelve, the other side may reject it.