flagr
flagr copied to clipboard
Add FlagRealtime entity
Description
Prepare a realtime table to track the last evaluated at timestamp for each flag. This helps to prevent premature flag deletion, and also we can surface some realtime information to the API and UI. The goal is to minimize the evaluation API overhead, and at the safe time, achieve the eventual consistency via its own DB.
- Async write to in-memory cache
- Periodically dump to DB (if it has newer evaluated at timestamp)
- Future read will just directly from DB
Motivation and Context
How Has This Been Tested?
Tested locally. TODO, more test coverage for flag_realtime.go
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
Related to #216
Hey we're evaluating this tool and it looks pretty good so far. I'm interested to know how multiple instances deal with updates, as evaluation logic uses in memory data, how other instance know it's time to get info from the database.
I guess this PR will solve this issue to, is that right? Probably those instances doesn't need to be up to date at millisecond rates but I would like to know your thoughts about it.
Thanks in advance
Hey we're evaluating this tool and it looks pretty good so far. I'm interested to know how multiple instances deal with updates, as evaluation logic uses in memory data, how other instance know it's time to get info from the database.
I guess this PR will solve this issue to, is that right? Probably those instances doesn't need to be up to date at millisecond rates but I would like to know your thoughts about it.
Thanks in advance
If you are referring to flags getting updated in the memory cache, you don't need to worry about that. Every flagr instance periodically pulls flags from either DB, local file, or remote HTTP endpoint. It's not at millisecond rates, it's controlled by FLAGR_EVALCACHE_REFRESHINTERVAL
.
But for this PR, I'm still thinking about what works best. Since from https://github.com/checkr/flagr/pull/247, I decoupled DB from its evaluation cache source. The evaluation node may not even have a DB connection, which makes it hard to share real-time information across the nodes via DB.
Cool thanks for answering. We're successfully running flagr on production working great so far!
We're interesting on this PR too
This helps to prevent premature flag deletion.
Do you need help to move this forward?
Stale pull request message