RFC: Request metadata ingress

[AndrewDryga]

In a microservice architecture there it is common to have a single shared dictionary which entries are used by a bunch of upstream services. Examples of these common libraries: list of USA states, a list of item colors which are available on an eCommerce website, address types, data range units and all sorts of general configuration.

To address this cases I want to propose a similar approach to the one that we use when building libraries. It is bad to hardcode configuration within a library or to set an API that allows to configure it (either via Apllication environment or via System environment). It is much more practical to accept all options as a function call arguments, offloading configuration management to a caller app.

Same we can do in a microservice environment - downstream service may take responsibility to fulfill an API call with all data that is required to handle the request and response without the need for an upstream to store state.

The gateway can store an in-memory (ETS table) cache of well-known dictionaries that is either pulled from configuration service (when Gateway starts or cache is missing) or pushed from it (when a configuration is changed and needs to be propagated).

A new upstream metadata plugin needs to be developed, which can be added to an API and contain settings for multiple dictionaries and rules how to fetch them.

A configuration update or cache drop API needs to be developed so that responsible service can reload the cache when it changed.

Pros

1. No need to cache or set all that data in an upstream service. Easier deployment (you won't ever forget to add new configuration environment variable), and easier configuration management for all system (only non-business related stuff can be stored in app configuration). Microservice is closer to a pure stateless app.
2. No additional latency is added because requesting a configuration from its store.
3. Configuration update propagates almost instantly without the need to build any kind of cache management in all configuration consumers.

Concerns

1. A configuration may be expensive to be sent on each request (network IO hit).
2. People may start to load too much data in this configuration store. Best practices and limitations must be well described in the documentation.

[AndrewDryga]

Alternative approach: build a package that stores this cache locally on upstream service but receives events from the gateway when cache needs to be updated (eg. cache generation sequence).