Skip to content

in-memory cache-sync server polling #3254

Description

@danoswaltCL

a thought: we could have our servers poll the db every n minutes to sync up the valid-experiment and valid-feature-flag data that we currently stash in-memory when users call /assign and /featureflag, instead of depending on random user-traffic to fetch that data and TTL to force refetch. there's not a good reason i can think of to only update when users make requests...

that would:

  • keep caches always 'warm' (no cold-cache issues when traffic is low)
  • keep server caches in-sync with each other and the db most of the time (currently each cache contains different information, and invalidation events are only picked up by one server at a time)
  • be much easier than trying to do many of the other optimizations we have talked about

aka, rare cache-misses, no need for cache-invalidation or TTL, and uniform state across the instances/db

i'm trying to think of the trade-off, technically it would be pulling in more data in-memory than it currently does, because it would need to get it for all contexts, but that's not really going to be that much more, and it would just be for currently running or paused experiments...

and it probably would be too much to keep all relevant segment data synced up, so maybe that doesn't change, and the precomputed-segment objects we're now caching are smaller than what has been stored in the past...

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions