• migration update: deployment_environments -> release_environments
• Storage Role Interface name refactor: DeploymentEnvironments -> ReleaseEnvironments
• move Environment related entity + storage contracts under the release domain

Context

When various components call the centralized release service multiple times across a single request, it becomes possible to receive a different flag state back during a single life cycle of a request.

Such use-case is when the customer uses a microservice architecture where release toggles were not part of the design initially. passing around feature toggle states becomes change with high cost. They would like to use the service without the need to update all the microservice to pass around this new data.

Proposal

Since the 12factor app conventions, many if not all distributed systems use some form of request tracing ID.

E.g.:

• Heroku: X-Request-ID
• AWS: X-Amzn-Trace-Id: Root=...

Using this tracing ID we can make a special kind of cache that is optimized for high throughput write/read operations for /v/config endpoint.

The scaling would be done on a per tracing-id mod cluster

While deleting an Environment or a Flag, either user should get a warning about existing ReleaseRollouts associated with them, or associated ReleaseRollouts should also be deleted

This will allow easy client generation for implementations

• create documentation
• generate go client from documentation
• add tests where the generated client is being used

Having Body structs makes swagger unusable:

ex:

type ListReleaseRolloutRequest struct {
	...
	// in: body
	Body struct{}
}

If an entity is mutated/deleted, then related caches must be invalidated.

• invalidate on Update
• invalidate on Delete