2021-03-06 - Where to store settings

In Config database table

Currently using a standarised DynamoDB table.

How to update setting

Adjust the setting in the table, all subsequent requests will use the new setting, this can be done by a client using RBAC to check they have security level to do so.

When to use

• Setting is used by one service only

  Many services may have the same setting but if we conceivably might want to update it at the per service level this method might be best

• Setting might change on a per deployment basis
• Setting might need to be changed on the fly

Example

serviceNames, so we have the power to quickly switch roll inter-service communications to new service's on a per service level, and might differ between deployments.

In an NPM module

Can be included in any code that needs the setting.

How to update setting

Update the module on NPM, services that use these settings need to update their package.json and re-deploy.

When to use

• Setting is shared across multiple services/repositories
• Setting does not change per implementation, is reasonably fixed for any expected deployment of the service
• Do no expect setting to change

Example

Izara market's graph tags are strings used to set the vertex label etc, these will be used by multiple services to query the graph. These should never change but there is the chance a tag need to be adjusted, rather than hardcoding into code which would be difficult to find all references across many services, place these into a required NPM module

Managed by a deployed service

This is a more messy but more serverless approach, a service maintains the setting and delivers it to other services that need to use it.

How to update setting

Other services could be responsible for the actual setting and either the setting service polls other services for their settings, or whenever the other services are deployed or their setting changes they deliver that to the setting service (either directly into the setting service's MsgIn queue, or into their own MsgOut queue which the setting service subscribes to).

If the setting service is directly responsible then could be handled using an endpoint with RBAC etc for client changing, or could re-deploy to update settings.

When a setting changes the setting service can either send to MsgIn queue of other services that need that setting, or (more common) will send to own MsgOut queue, other services that need the setting subscribe to that.

When to use

• More complex setting management
• Setting is shared across multiple services/repositories
• Can manage settings that come from a non-strictly defined number of other services
• Expect settings to change reasonably regularly and not want to redeploy or update dependent services each time a setting changes

Example

Service - Message Config Manager, planning on having services trigger the Message Config Manager to update that service's message configs each time it is deployed, and to spread any changes out to dependent services.