A feature flag is toggled in the strategy database at 10:03 AM. By 10:10, half the application servers are using the new search flow and half are still using the old one. Support has screenshots from both. Engineering cannot reproduce the mismatch because their test environment has one process and one cache.
The strategy database was meant to move feature flags, experiments, pricing rules, approval workflows, and segmentation out of code. Change a row instead of deploying. Let business strategy move faster than release cycles.
That works until the row becomes part of application state. The flag is cached. The rule references fields the code does not support. The experiment points to a variant that does not exist. The pricing change creates orders that cannot be unpriced. The data update is fast. The system it touches is not.
Feature Flags Still Need Coordination
A flag table starts cleanly.
class FeatureFlags:
_cache = {}
@classmethod
def is_enabled(cls, flag_name):
if flag_name not in cls._cache:
cls._cache[flag_name] = db.query(
"SELECT enabled FROM feature_flags WHERE name = %s",
(flag_name,)
)[0]['enabled']
return cls._cache[flag_name]
def search(query):
if FeatureFlags.is_enabled('new_search'):
return new_search_implementation(query)
return legacy_search_implementation(query)Real-time database reads are too slow at production volume, so the application caches the value. The database changes. The cache does not. Some processes restart and pick up the new value. Others keep the old one.
The flag did not remove deployment coordination. It moved coordination into cache invalidation, process restarts, rollout ordering, and observability. If those mechanisms do not exist, the database update becomes an untracked deployment.
Business Rules Smuggle Schema Dependencies
Approval rules often become JSON blobs.
{
"rule_id": "expense_approval",
"conditions": {
"amount_greater_than": 1000,
"category_in": ["travel", "equipment"]
},
"actions": {
"require_approval_from": ["manager", "finance"]
}
}Then someone adds a rule using fields the application does not know how to read.
{
"rule_id": "project_expense_approval",
"conditions": {
"project_phase": "execution",
"vendor_type": "external"
},
"actions": {
"require_approval_from": ["project_manager", "procurement"]
}
}The database accepts it. The rules UI may have prevented it, but APIs, SQL scripts, imports, and manual edits can bypass UI validation. The evaluator reaches project_phase, finds no supported field, and fails at runtime.
The rule is data. The dependency is code. The database has no idea which fields the application supports unless that contract is modeled and enforced.
Experiments Fail Quietly
A/B configuration looks like business-owned data.
def assign_variant(user_id, experiment_name):
config = db.query(
"SELECT * FROM experiments WHERE name = %s AND active = true",
(experiment_name,)
)[0]
hash_val = hash(f"{user_id}:{experiment_name}") % 100
cumulative = 0
for variant, percentage in config['variants'].items():
cumulative += percentage
if hash_val < cumulative:
return variantA distribution is updated during the experiment.
{
"experiment": "checkout_flow",
"variants": {
"control": 45,
"treatment_a": 45,
"treatment_b": 5
}
}The percentages sum to 95. Five percent of users fall through without a variant. Checkout breaks for them. Metrics show the treatment performing poorly. The experiment analysis blames the design, not the configuration error.
Validation that checks “positive integer” is not enough. The configuration has domain rules: percentages sum to 100, variants exist in code, users retain stable assignment, and changes do not strand existing sessions.
Pricing Changes Need History
Pricing rules are often edited directly because the business needs speed.
CREATE TABLE pricing_rules (
rule_id SERIAL PRIMARY KEY,
customer_segment VARCHAR(50),
product_category VARCHAR(50),
discount_percentage DECIMAL(5,2),
effective_date DATE,
expiration_date DATE
);A promotion moves from 10% to 15%. The row is updated. Two weeks later revenue is low and nobody can reconstruct the previous value, who changed it, or why. The table stores current strategy, not the path that created it.
A worse update applies a 50% discount to all enterprise customers instead of a narrow segment. Orders are placed. Fulfillment begins. Reverting the row stops future discounts. It does not reprice orders already created under the wrong rule.
A strategy database without audit history and effective dating is a current-state machine. Business decisions usually need a ledger.
Rows Retire Without Leaving
Segmentation tables accumulate inactive rows.
| segment_id | name | criteria | active | created_at | updated_at |
|---|---|---|---|---|---|
| 1 | enterprise | revenue > 100000 | true | 2023-01-15 | 2023-01-15 |
| 2 | mid_market | revenue BETWEEN 10000 AND 100000 | true | 2023-01-15 | 2023-01-15 |
| 3 | smb | revenue < 10000 | true | 2023-01-15 | 2023-01-15 |
| 4 | trial_users | trial_active = true | false | 2023-03-10 | 2024-08-22 |
| 5 | beta_testers | beta_access = true | false | 2023-06-01 | 2024-01-30 |
Inactive may mean temporarily disabled, retired, preserved for historical reporting, or unsafe to delete. Operators keep the rows because deletion is irreversible and dependencies are unclear.
Historical orders may reference old segment IDs. Foreign keys prevent deletion. Someone removes the constraint to preserve order history while allowing cleanup. Now old records can point to missing segments. Another part of the application still evaluates inactive segments through a legacy path.
The table becomes append-only by accident. Cleanup needs lifecycle states, ownership, dependency checks, and archival policy. A boolean active cannot carry all of that.
Rollback Does Not Rewind Derived State
A flag launches a new payment processor. For 24 hours, some transactions are created in the new processor’s schema. Failures appear. The flag is disabled.
New payments stop using the processor. Existing transactions still exist in the new schema. Status checks now have to understand both processors. In-progress payments need cleanup or migration. The old state did not come back just because the new flag went false.
Experiment rollbacks have the same shape. Users already assigned to variants keep their assignment unless the system explicitly reassigns them. Workflow rule changes leave documents mid-process under old rules while new documents follow new rules.
Strategy data changes produce application state, user state, and external side effects. Reverting the row only changes future evaluation.
Configuration Becomes Code Without Code Safety
Feature flags often grow from booleans into a rule engine.
CREATE TABLE feature_flags (
flag_name VARCHAR(100),
enabled BOOLEAN,
rollout_percentage INTEGER,
enabled_for_segments JSON,
enabled_for_users JSON,
requires_flags JSON,
conflicts_with_flags JSON,
evaluation_logic TEXT
);Then evaluation_logic stores runtime expressions.
def is_enabled(flag_name, user):
flag = db.query(
"SELECT * FROM feature_flags WHERE flag_name = %s",
(flag_name,)
)[0]
if not flag['enabled']:
return False
if flag['evaluation_logic']:
return eval(flag['evaluation_logic'], {'user': user})A typo is now a production behavior change stored in a row. There is no compiler, no review, no unit test unless the organization builds those around the data. Debugging moves from reading code to inspecting database contents.
Configuration as data scales only when data gets the safety rails code already has: schema validation, dependency checks, version control, review, tests, audit history, rollout controls, and rollback plans.
Migrations Re-Couple Code and Data
A pricing schema changes from discount_percentage to discount_amount so fixed discounts can be supported.
ALTER TABLE pricing_rules RENAME COLUMN discount_percentage TO discount_amount;
ALTER TABLE pricing_rules ADD COLUMN discount_type VARCHAR(20) DEFAULT 'percentage';The new application reads discount_amount. The old one reads discount_percentage. A rollback after fixed-amount rows exist cannot recover the old meaning without data loss or translation. Code rollback is no longer enough because the data shape changed.
The strategy database is still application schema. It just changes through a different door.
Safer Strategy Data Looks Less Like a Shortcut
Systems that survive this pattern usually add the mechanisms the first version skipped:
- append-only configuration versions instead of destructive updates
- effective dates and expiration dates
- audit history with actor and reason
- schema validation against supported fields and variants
- transitive dependency checks for flags and rules
- cache invalidation across running processes
- idempotent side effects and cleanup paths
- staging and review for high-risk changes
At that point the strategy database is no longer a quick table for business users. It is a deployment system for strategic data.
Encoding strategy in code with a fast deployment pipeline can be slower per change and safer overall. Using a database can work when dependencies are explicit and changes are validated before production. The failure mode is pretending that moving logic into rows removed the need for deployment discipline.
A strategy database makes change easy to apply. Production systems care whether the change is safe to absorb.
