Support multiple AWS regions without shared singleton cache interference #3

Summary

We are integrating DTE support for multiple AWS regions and identified a limitation related to how the library manages configuration caching via singletons.

Background

Our exchanger is deployed in a single AWS region (us-east-1), but it bids across multiple RTBs distributed in different regions:

• us-east-1
• eu-west-1
• ap-southeast-1

To use the DTE library, we call NewRequestEvaluator, which requires a bucket name and its corresponding region. A natural approach for multi-region support is to create separate evaluators per AWS region.

Problem

From reviewing the implementation, it appears that the library uses singleton-based cache(s) for storing configuration data.

When periodic update tasks refresh the cache:

• the existing cache is cleared and replaced
• this impacts all evaluators globally, regardless of region

This creates a conflict when running multiple evaluators (one per region) in the same process, as updates for one region may overwrite or invalidate data used by others.

Expected behavior

We would like to be able to:

• run multiple RequestEvaluator instances concurrently
• each tied to a different AWS region and S3 bucket
• without cache interference between regions

Actual behavior

• Cache is shared globally (singleton)
• Periodic updates clear and repopulate the cache
• Evaluators across regions may read inconsistent or incorrect configuration data

Feature request

We would like to request support for multi-region usage in a single process. Possible approaches could include:

1. Region-scoped cache

   • Maintain separate cache instances per region (or per evaluator)
   • Avoid global cache invalidation across unrelated regions

2. Dependency injection for cache

   • Allow passing a cache instance into NewRequestEvaluator
   • Let users manage isolation explicitly

3. Namespacing cache keys

   • Partition cache entries by region/bucket to prevent collisions

4. Non-singleton design

   • Avoid global state where feasible, or provide an option to disable singleton behavior

Question

What is the recommended way to support multiple AWS regions using the current library design without deploying separate exchangers per region?

Notes

We’re happy to contribute a PR if there is alignment on the preferred approach.