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: build/render_hook_docs/DECISION_TREE_FORMAT.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -137,6 +137,7 @@ scope: documents
137
137
7. **Use meaningful scopes**: Choose scope values that clearly indicate the tree's domain (e.g., `documents`, `collections`, `sequences`)
138
138
8. **Add sentiment for suitability trees**: If your tree determines whether something is suitable (not just choosing between options), use `sentiment: "positive"` and `sentiment: "negative"` to provide visual feedback
139
139
9. **Be consistent with sentiment**: In a suitability tree, ensure all positive outcomes have `sentiment: "positive"` and all negative outcomes have `sentiment: "negative"` for clarity
140
+
10. **Control answer order**: The order of `yes` and `no` in the YAML controls the visual layout. For early rejection patterns, put `no` first so negative outcomes appear on the left side of the diagram
Copy file name to clipboardExpand all lines: build/render_hook_docs/DECISION_TREE_IMPLEMENTATION_NOTES.md
+30Lines changed: 30 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -167,3 +167,33 @@ outcome:
167
167
168
168
**Backward Compatibility**: Existing trees without sentiment fields continue to work with default red styling. This allows gradual adoption.
169
169
170
+
## 12. Answer Order Respects YAML Structure
171
+
172
+
**Discovery**: The JavaScript had two issues preventing YAML answer order from being respected:
173
+
1. The `flattenDecisionTree()` function was hardcoded to process "yes" first, then "no"
174
+
2. The tree line drawing code was deriving Yes/No labels from position (first child = Yes, others = No) instead of using the actual answer value
175
+
176
+
**Problem**: This prevented authors from controlling the visual layout of the tree. If you wanted "no" outcomes to appear first (for early rejection patterns), the diagram would still show "yes" first.
177
+
178
+
**Solution**:
179
+
1. Modified `flattenDecisionTree()` to iterate through answer keys in the order they appear in the YAML
180
+
2. Modified `drawTreeLines()` to use the actual `answer` value stored in each item instead of deriving it from position
181
+
182
+
```javascript
183
+
// In flattenDecisionTree():
184
+
const answerKeys = Object.keys(question.answers);
185
+
answerKeys.forEach(answerKey => {
186
+
const answer = question.answers[answerKey];
187
+
// Process in order, storing answer.value in the item
188
+
});
189
+
190
+
// In drawTreeLines():
191
+
answerLabel = item.answer || 'Yes'; // Use stored value, not position
192
+
```
193
+
194
+
**Benefit**: Authors can now control tree layout by ordering answers in the YAML:
195
+
- Put `no` first for early rejection patterns (negative outcomes appear left)
196
+
- Put `yes` first for positive-path-first patterns (positive outcomes appear left)
197
+
198
+
**Key Insight**: YAML object key order is preserved in JavaScript (since ES2015), and we now respect both the order AND the actual answer values, making the layout fully author-controlled.
- You don’t need to perform join operations on the data from several tables
42
+
into a nested Redis JSON object.
43
+
- RDI supports the data transformations you need for your app.
44
+
- Your data caching needs are too complex or demanding to implement and maintain yourself.
45
+
- Your database administrator has reviewed RDI's requirements for the source database and
46
+
confirmed that they are acceptable.
47
+
48
+
## When not to use RDI
49
+
50
+
RDI is not a good fit when:
51
+
52
+
- You are migrating an existing data set into Redis only once.
53
+
- Your app needs *immediate* cache consistency (or a hard limit on latency) rather
54
+
than *eventual* consistency.
55
+
- You need *transactional* consistency between the source and target databases.
56
+
- The data is ingested from two replicas of Active-Active at the same time.
57
+
- The app must *write* data to the Redis cache, which then updates the source database.
58
+
- Your data set will only ever be small.
59
+
- Your data is updated by some batch or ETL process with long and large transactions - RDI will fail
60
+
processing these changes.
61
+
- You need complex stream processing of data (aggregations, sliding window processing, complex
62
+
custom logic).
63
+
- You need to write data to multiple targets from the same pipeline (Redis supports other
64
+
ways to replicate data across Redis databases such as replicaOf and Active Active).
65
+
- Your database administrator has rejected RDI's requirements for the source database.
66
+
67
+
## Decision tree for using RDI
68
+
69
+
Use the decision tree below to determine whether RDI is a good fit for your architecture:
70
+
71
+
```decision-tree {id="when-to-use-rdi"}
72
+
id: when-to-use-rdi
73
+
scope: rdi
74
+
rootQuestion: cacheTarget
75
+
questions:
76
+
cacheTarget:
77
+
text: |
78
+
Do you want to use Redis as the target database for caching data?
79
+
whyAsk: |
80
+
RDI is specifically designed to keep Redis in sync with a primary database. If you don't need Redis as a cache, RDI is not the right tool.
81
+
answers:
82
+
no:
83
+
value: "No"
84
+
outcome:
85
+
label: "RDI is not necessary - you don't need Redis as a cache"
86
+
id: noRedisCache
87
+
sentiment: "negative"
88
+
yes:
89
+
value: "Yes"
90
+
nextQuestion: singleSource
91
+
singleSource:
92
+
text: |
93
+
Are you transferring data from a single source database?
94
+
whyAsk: |
95
+
RDI is designed to work with a single source database. Multiple sources or Active-Active replicas create conflicting change events.
96
+
answers:
97
+
no:
98
+
value: "No"
99
+
outcome:
100
+
label: "RDI won't work - you need a single source database"
101
+
id: multipleSourcesOrActiveActive
102
+
sentiment: "negative"
103
+
yes:
104
+
value: "Yes"
105
+
nextQuestion: systemOfRecord
106
+
systemOfRecord:
107
+
text: |
108
+
Is the source database your system of record?
109
+
whyAsk: |
110
+
RDI requires the source database to be the authoritative source of truth. If your app writes to Redis first, RDI won't work.
111
+
answers:
112
+
no:
113
+
value: "No"
114
+
outcome:
115
+
label: "RDI won't work - the source database must be the system of record"
116
+
id: notSystemOfRecord
117
+
sentiment: "negative"
118
+
yes:
119
+
value: "Yes"
120
+
nextQuestion: appWritesToDb
121
+
appWritesToDb:
122
+
text: |
123
+
Does your app always write its data to the source database?
124
+
whyAsk: |
125
+
RDI requires the app to write to the source database first. If your app writes to Redis first, RDI cannot maintain consistency.
126
+
answers:
127
+
no:
128
+
value: "No"
129
+
outcome:
130
+
label: "RDI won't work - your app must write to the source database"
131
+
id: appWritesToRedis
132
+
sentiment: "negative"
133
+
yes:
134
+
value: "Yes"
135
+
nextQuestion: consistency
136
+
consistency:
137
+
text: |
138
+
Can your app tolerate eventual consistency in the Redis cache?
139
+
whyAsk: |
140
+
RDI provides eventual consistency, not immediate consistency. If your app needs real-time cache consistency or hard latency limits, RDI is not suitable.
141
+
answers:
142
+
no:
143
+
value: "No"
144
+
outcome:
145
+
label: "RDI is not suitable - you need immediate cache consistency"
146
+
id: needsImmediate
147
+
sentiment: "negative"
148
+
yes:
149
+
value: "Yes"
150
+
nextQuestion: deployment
151
+
deployment:
152
+
text: |
153
+
Do you want a self-managed solution or an AWS-based solution?
154
+
whyAsk: |
155
+
RDI is available as a self-managed solution or as an AWS-based managed service. If you need a different deployment model, RDI may not be suitable.
156
+
answers:
157
+
no:
158
+
value: "No"
159
+
outcome:
160
+
label: "RDI may not be suitable - check deployment options"
161
+
id: deploymentMismatch
162
+
sentiment: "negative"
163
+
yes:
164
+
value: "Yes"
165
+
nextQuestion: dataChangePattern
166
+
dataChangePattern:
167
+
text: |
168
+
Does your source data change frequently in small increments?
169
+
whyAsk: |
170
+
RDI captures changes from the database transaction log. Large batch transactions or ETL processes can cause RDI to fail.
171
+
answers:
172
+
no:
173
+
value: "No"
174
+
outcome:
175
+
label: "RDI will fail with batch/ETL processes and large transactions"
176
+
id: batchProcessing
177
+
sentiment: "negative"
178
+
yes:
179
+
value: "Yes"
180
+
nextQuestion: changeRate
181
+
changeRate:
182
+
text: |
183
+
Are there no more than 10K changes per second in the source database?
184
+
whyAsk: |
185
+
RDI has throughput limits. Exceeding these limits will cause processing failures and data loss.
186
+
answers:
187
+
no:
188
+
value: "No"
189
+
outcome:
190
+
label: "RDI throughput limits will be exceeded"
191
+
id: exceedsChangeRate
192
+
sentiment: "negative"
193
+
yes:
194
+
value: "Yes"
195
+
nextQuestion: dataSize
196
+
dataSize:
197
+
text: |
198
+
Is your total data size not larger than 100GB?
199
+
whyAsk: |
200
+
RDI has practical limits on the total data size it can manage. Very large datasets may exceed these limits.
201
+
answers:
202
+
no:
203
+
value: "No"
204
+
outcome:
205
+
label: "RDI may not be suitable - your data set is too large"
206
+
id: dataTooLarge
207
+
sentiment: "negative"
208
+
yes:
209
+
value: "Yes"
210
+
nextQuestion: joins
211
+
joins:
212
+
text: |
213
+
Do you not need to perform join operations on data from several tables into a nested Redis JSON object?
214
+
whyAsk: |
215
+
RDI has limitations with complex join operations. If you need to combine data from multiple tables into nested structures, you may need custom transformations.
216
+
answers:
217
+
no:
218
+
value: "No"
219
+
outcome:
220
+
label: "RDI may not be suitable - complex joins are not well supported"
221
+
id: complexJoins
222
+
sentiment: "negative"
223
+
yes:
224
+
value: "Yes"
225
+
nextQuestion: transformations
226
+
transformations:
227
+
text: |
228
+
Does RDI support the data transformations you need for your app?
229
+
whyAsk: |
230
+
RDI provides built-in transformations, but if you need custom logic beyond what RDI supports, you may need a different approach.
231
+
answers:
232
+
no:
233
+
value: "No"
234
+
outcome:
235
+
label: "RDI may not be suitable - required transformations are not supported"
236
+
id: unsupportedTransformations
237
+
sentiment: "negative"
238
+
yes:
239
+
value: "Yes"
240
+
nextQuestion: adminReview
241
+
adminReview:
242
+
text: |
243
+
Has your database administrator reviewed and confirmed that RDI's requirements for the source database are acceptable?
244
+
whyAsk: |
245
+
RDI has specific requirements for the source database (binary logging, permissions, etc.). Your DBA must confirm these are acceptable before proceeding.
246
+
answers:
247
+
no:
248
+
value: "No"
249
+
outcome:
250
+
label: "RDI is not suitable - database administrator has rejected RDI's requirements"
0 commit comments