Caching and Deployment

The Maconomy web client uses a configuration-driven deployment model. Each deployment includes updated JSON configuration files that define various aspects of the client’s behavior. These configurations are managed and served by the coupling service, which ensures that clients receive updates in a controlled and efficient manner.

How Caching Works

To optimize performance and reduce unnecessary server load, the system uses a layered caching mechanism:

• Server Polling Interval The coupling service checks for new configuration files at regular intervals, defined by:

  cache.client-configuration.update-interval = 60
  

  This means the server will detect and load new configurations within 60 seconds of deployment.

• Client-Side Cache Expiration Once the server has picked up a new configuration, clients will only fetch it after their local cache expires. This is controlled by:

  web.services.cache.cache-control.configurations = max-age=300
  

  Clients will wait up to five minutes (300 seconds) before revalidating their cached configuration.

• Disabling Caching (Optional) Caching can be disabled entirely by setting:

  web.services.configurations.cache.enabled = false
  

  However, note that this only affects future requests. Clients that have already cached a configuration will still wait for their cache to expire before checking for updates.

All of these settings are defined in the settings.ini file on the server.

---

Deployment Planning and Cache Considerations

To ensure a smooth rollout of new configurations while respecting the client-side caching behavior, follow these best practices:

1. Understand the Timing

With the default settings:

• The server picks up changes within 60 seconds.
• Clients may take up to five minutes to reflect those changes.

This results in a maximum delay of approximately six minutes from deployment to full client adoption.

2. Schedule Deployments Strategically

• Deploy during low-traffic periods to minimize user impact.
• Allow at least six minutes post-deployment before expecting all clients to reflect the new configuration.

3. Accelerate Propagation (Optional)

If faster rollout is needed:

• Temporarily reduce the max-age value (for example, to 60 seconds) before deployment.
• Restore the original value after the rollout window.

This ensures clients revalidate more frequently during the critical update period.

4. Communicate with Stakeholders

• Inform users or support teams about the expected delay in configuration visibility.
• This helps manage expectations and reduces confusion during the transition.

5. Monitor and Validate

Use monitoring tools or test clients to verify the following:

• The server has picked up the new configuration.
• Clients are receiving the updated configuration after the expected delay.