docs: first draft multi-synch-sources ADR #1636
Conversation
Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
dosubot
bot
added
the
size:M
✅ Deploy Preview for polite-licorice-3db33c ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| Flagd daemon is a feature flag evaluation engine that forms a core part of the OpenFeature ecosystem. Unlike OpenFeature SDK components, which are, by design, agnostic to the specifics of flag structure, evaluation, and persistence, Flagd must take an opinionated stance about how feature-flags look, feel, and act. What schema best describes a flag? How should they be evaluated? And in what sort of persistence layer should they be stored? | ||
|
|
||
| This latter-most question -- _how should they be stored_ -- is the most opaque design detail of every commercial flagging product from the perspective its end-users. As a front-line engineer using a commercial flagging product, I may, for example, be exposed to flag schema by the product's SDK, and become familiar with its evaluation intricacies over time as my needs grow to require advanced features, or as I encounter surprising behavior. Rarely, however, is an end-user exposed to the details of a commercial product's storage backend. The SaaS vendor is expected to engineer a safe, fast, multi-tenant storage back-end, optimized for its flag schema and operational parameters, and insulate the customer from these details via its SDK. This presents Flagd, an open-source evaluation engine, with an interesting conundrum: what sort of flag storage best suits the needs of its potential user-base (which is everyone)? |
There was a problem hiding this comment.
This is a good thing to mention.
| <!-- | ||
| Unsure whether we want a diagram in this section or not. Happy to add one if we want one. | ||
| --> | ||
| The solution to the conundrum posited in the background section of this document is to decouple flag storage entirely from the rest of the runtime, including instead support for myriad commonly used data synchronization interfaces. This allows Flagd to be agnostic to flag storage, while enabling users to use whichever storage back-end best suits their environment. |
There was a problem hiding this comment.
I think it might be good to add something to drive the point home here, in terms of syncs essentially being "resources" in the "URI" sense of the term... any flag configuration that you could locate as a URI is possibly a reasonable sync type (http:, file:, grpc:, ftp:, etc, etc, etc).
| <!-- | ||
| Unsure whether we want a diagram in this section or not. Happy to add one if we want one. | ||
| --> |
There was a problem hiding this comment.
Not needed IMO, but wouldn't hurt 🤷
There was a problem hiding this comment.
I'm basically ready to approve this with the exception of some structural and grammatical changes. Really nice doc, thanks @djosephsen
toddbaert
requested review from
cupofcat,
dominikhaska,
beeme1mr,
askpt,
aepfli,
alexandraoberaigner and
guidobrei
|
@djosephsen running |
|
|
||
| The goal of first-class multi-sync support generally is to broaden Flagd's potential to suit the needs of many different types of engineers, operating in many different contexts. By decoupling flag persistence from the runtime, Flagd can focus on evaluation and sync, while enabling its user-base to choose a persistence layer that best suits their individual requirements. | ||
|
|
||
| ## Background |
There was a problem hiding this comment.
Trying to understand more of the background - is this a backfill ADR?
It also confuses me a bit as I don't see the connection between storage and multi sync sources - is the concern around the data consistency?
There was a problem hiding this comment.
This is another "retrospective/historical" ADR, the one @djosephsen volunteered to do at our last meeting. It's explaining our multi-sync support, documented here: https://flagd.dev/reference/sync-configuration/ (basically explaining why we created this interface and why we want to support fetching flags from various resources).
| <!-- | ||
| Unsure whether we want a diagram in this section or not. Happy to add one if we want one. | ||
| --> | ||
| The solution to the conundrum posited in the background section of this document is to decouple flag storage entirely from the rest of the runtime, including instead support for myriad commonly used data synchronization interfaces. This allows Flagd to be agnostic to flag storage, while enabling users to use whichever storage back-end best suits their environment. |
There was a problem hiding this comment.
What the interface of the storage you have in mind when coming up with this proposal? The existing implementation or there's another new proposal?
There was a problem hiding this comment.
This is a backfill ADR for the existing ISync interface.
| updated: 2025-05-21 | ||
| --- | ||
|
|
||
| # ADR: Multiple Sync Sources |
There was a problem hiding this comment.
Sorry, I still don't get the high-level idea after reading the ADR - are we trying to change something for config syncing or flag (and other data) storage of flagd?
There was a problem hiding this comment.
No changes are intended, this ADR is an attempt to explain the rationale for the existing ISync interface, and the project's support for multiple sync-sources.
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Dave Josephsen <dave.josephsen@gmail.com>
Intent of this PR is to add the first draft of the multi-synch-sources ADR, this is a docs-only change