Goten Design

The goten framework is designed for services to be:

• spreading across multiple clusters in different regions
• running with different versions at the same time

which means, Goten is aware of:

• multi-services
• multi-regions
• multi-versions

We must think of it as a protocol between those entities.

Protocol, because there must be some established communication that enforces database schema stability despite swimming in this tri-dimensional environment. We can’t use any database features. Even global databases with regional replication would not work, because services are not even guaranteed to work on the same database backend. Goten was shown to be a kind of language on top of protobuf because of extended types. Now, we see it needs some protocol on top of gRPC too, to ensure some global correctness.

Since this is all integrated, we will also describe how multi-region design works from an implementation point of view. We assume you have a basic knowledge of the multi-region design as explained in the developer guide, which describes:

1. regional resources
2. MultiRegionPolicy object
3. the region information included in the name field

The developer guide also explains the multi-version concept in the migration section.

With that knowlege in place, we will discuss four important concepts:

1. Meta service as the service registry service
2. EnvRegistry as the service discovery object
3. the resource metadata for the service synchronization
4. the multi-region policy store

with the protocol call flows and the actual implementation.