You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/essentials/architecture.md
+5-45Lines changed: 5 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,12 +35,6 @@ various SDK architectures have generally been fully implemented.
35
35
6. Finally, an update notification is pushed to all connected SDKs via a server-sent event (SSE) connection
36
36
that informs them that new configuration data updates are available.
37
37
38
-
DevCycle's feature flag evaluation path is completely separate from the Management API and Dashboard used to manage
39
-
those feature flags. This separation ensures that even if the Management API or Dashboard experiences an outage,
40
-
feature flag evaluations can continue uninterrupted.
41
-
This allows us to provide our highest level of SLA uptime guarantees for feature flag evaluations—the
42
-
most critical part of our service.
43
-
44
38
## Shared Bucketing and Segmentation Library
45
39
46
40
The shared bucketing and segmentation library is the core of our SDKs and API logic. It combines configuration data
@@ -73,12 +67,10 @@ we have built a native implementation, for example, in our [GO SDK](https://gith
73
67
74
68
1. On initialization, the Server SDK retrieves the configuration data from the CDN and stores it locally.
75
69
76
-
2. On each `variableValue()` / `variable()` call, the bucketing and segmentation library combines user data, device
77
-
data,
70
+
2. On each `variableValue()` / `variable()` call, the bucketing and segmentation library combines user data, device data,
78
71
and configuration data locally to bucket users into features and variations to determine variable values.
79
72
80
-
3. Configuration updates are received through a real-time server-sent event (SSE) connection or as a backup via polling
81
-
against the CDN.
73
+
3. Configuration updates are received through a real-time server-sent event (SSE) connection or as a backup via polling against the CDN.
82
74
83
75
4. Event data is aggregated within the SDK and sent to the Events API on an interval.
84
76
@@ -88,8 +80,7 @@ we have built a native implementation, for example, in our [GO SDK](https://gith
88
80
89
81
For most use cases, local bucketing SDKs provide superior performance and reliability.
90
82
However, the cloud-bucketing SDKs can make integration easier for specific use cases where access to
91
-
[EdgeDB](/platform/feature-flags/targeting/edgedb) to integrate user data between client-side and backend applications
92
-
is needed.
83
+
[EdgeDB](/platform/feature-flags/targeting/edgedb) to integrate user data between client-side and backend applications is needed.
93
84
94
85
1. On each `variableValue()` / `variable()` call, the Cloud Bucketing Server SDKs fetch data from the
95
86
[Bucketing API](/bucketing-api/) served by Cloudflare Workers at the edge.
@@ -120,28 +111,10 @@ is needed.
120
111
121
112
## Latency vs. Data Storage
122
113
123
-
DevCycle was designed and built for **performance** and **reliability** first. To enable Feature Flags to evaluate
124
-
quickly and be served from as close to the end user as possible, we chose to not store user data to our servers by
125
-
default. This means that all Feature and Variable evaluations happen using the user information provided at the time of
126
-
the request, avoiding database lookups and keeping latency extremely low.
127
-
128
-
For teams that **do** need to persist user attributes for targeting or other advanced use cases, DevCycle offers
129
-
**EdgeDB**: a globally distributed, edge-based data store that allows you to save and retrieve user data with minimal
130
-
latency. Read more about it at [EdgeDB and Stored Properties](/platform/feature-flags/targeting/edgedb).
114
+
DevCycle was designed and built for **performance** and **reliability** first. To enable Feature Flags to evaluate quickly and be served from as close to the end user as possible, we chose to not store user data to our servers by default. This means that all Feature and Variable evaluations happens using the user information provided at the time of the request, avoiding database lookups and keeping latency extremely low.
131
115
132
-
### SDK Performance Summary
116
+
For teams that **do** need to persist user attributes for targeting or other advanced use cases, DevCycle offers **EdgeDB**: a globally distributed, edge-based data store that allows you to save and retrieve user data with minimal latency. Read more about it at [EdgeDB and Stored Properties](/platform/feature-flags/targeting/edgedb).
133
117
134
-
Our SDKs are designed to fit into a variety of use cases, balancing performance, reliability, and data privacy. Below is a summary of the expected performance characteristics of each SDK type and configuration:
135
-
These numbers are approximate and can vary based on network conditions, geographic
136
-
deployment, and specific implementation details in various configurations.
|**Go Server SDK**| 20-50ms initialization. 100-200 nanosecond evaluations post-initialization. | 20-50ms per evaluation. Latency is relative to the distance to the nearest Cloudflare PoP. | Depends on customer deployment architecture. Evaluation times within the SDK proxy are measured in nanoseconds, with HTTP responses given in microseconds. |
142
-
|**PHP Server SDK**| N/A | 20-50ms per evaluation. Latency is relative to the distance to the nearest Cloudflare PoP. | Depends on customer deployment architecture. Evaluation times within the SDK proxy are measured in nanoseconds, with HTTP responses given in microseconds. |
143
-
|**All Other Server SDK**| 20-50ms initialization. Sub-ms Variable evaluations post-initialization. | 20-50ms per evaluation. Latency is relative to the distance to the nearest Cloudflare PoP. | Depends on customer deployment architecture. Evaluation times within the SDK proxy are measured in nanoseconds, with HTTP responses given in microseconds. |
144
-
|**SDK Proxy**| 20-50ms initialization. 100-200 nanosecond evaluations post-initialization. | While possible, this is not a supported configuration of the SDK Proxy. | Exact performance depends on customer deployment specifics. Evaluations as fast as hundreds of nanoseconds. HTTP responses as fast as microseconds. |
145
118
146
119
## SDK Test Harness
147
120
@@ -152,16 +125,3 @@ a set of HTTP requests made to a series of locally run proxy servers for each SD
152
125
These proxy servers then take the commands from the requests made from the tests to set up the SDKs in different ways,
153
126
execute all the core SDK methods, and measure their responses. They ensure that each SDK behaves the same way,
154
127
returns the same results, or throws the same errors for each test.
155
-
156
-
## Management API / Dashboard
157
-
158
-
DevCycle's Management API and Dashboard are designed using high availability principles to ensure that users can manage
159
-
their feature flags and configurations without interruption. The Management API is multi-region, ensuring that if one
160
-
region experiences
161
-
an outage, traffic can be routed to another healthy region. The Dashboard is served via Vercel's multi-region
162
-
architecture,
163
-
which provides automatic failover and load balancing across regions.
164
-
165
-
We use an active-active architecture for our failover systems, meaning that multiple regions are running simultaneously and can handle traffic at any time, ensuring that our Management API can maintain high
0 commit comments