Configuration as data

(Section: Architecture and Protocols)

1) The idea and difference from "configuration as code"

Configuration as Data (CaD) is a representation of configuration as a typed, declarative, validated model, independent of executable code and managed as business data: with versions, schemas, migrations, audits and tests.
Unlike "configuration as code," where the logic of generating configs lives in templates/scripts, CaD excludes imperative from the source of truth: no loops, conditions, and hidden logic within configs. All - clean data + strict scheme + policies.

Key goals: predictability, diff ability, change safety, fast rollbacks, the ability to deliver progressively and automatically control compliance.

2) Principles of "config as data"

1. Declarativeness and unambiguity: we describe the desired state, not the steps of achievement.
2. Type safety and schemes: JSON Schema/Protobuf/Avro/OpenAPI for strict contracts.
3. Artifact immutability: config shots are versioned and signed (provenance).
4. Validation and policy: in pipeline - syntax → semantics → policy-as-code (OPA, rules).
5. Observability of configs: version fingerprint in logs/metrics/traces.
6. Responsibility sharing: data (config), schema (contract), policy (restrictions), controller (implementation).
7. Modularity and layers: global, regional, tenant-, product, feature levels, with predictable merge and priorities.

3) Configuration Simulation: Schema as Contract

Entity families: routing, limits, phicheflags, tariffs, AB segments, quotas, risk rules, financial settings, etc.
Types: explicit enum/oneOf, ranges, regex, referential integrity (ref/ID).
Schema versioning: 'v1 → v1beta2 → v2' (rejection plan, migrations).
Defaulting/Mutation: safe defaults at the validation stage; deterministic order of application.
Constraints: business constraints (for example, 'rateLimit <= 2000 rps' on tenant).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Layers, inheritance, and conflict resolution

Иерархия: `global → region → environment → tenant → product → cohort → user`.
Merge rules: declarative - "the last won" (override) or strategic (merge/patch/replace per field).
Validation at intersections: prohibit conflicting keys, require explicit override.
Visualization of the final effective config is required (deterministic diffusions).

5) Configuration life cycle (GitOps paradigm)

1. Source of truth: repository with data + schemas + policies.

• syntax check (lint),
• validation according to the scheme,
• semantic checks/tests,
• policy-as-code (e.g. OPA/Rego),
• safe migrations (see § 7),
• signature and publication of the snapshot.
• 3. Promotion: PRs between directories' dev/qa/staging/prod'or rings' ring-0/.../ring-N '.
• 4. Delivery: controllers/operators pull up fresh snapshots, apply through a reconcile cycle.
• 5. Audit and reversibility: all changes are traced; rollback - revert commit/rollback snapshot.

6) Delivery and distribution of configs

Static (pull-on-start): load the snapshot at the start, restart to update.
Dynamic (watch/stream): etcd/Consul/ZooKeeper, Kubernetes API/CRD, proprietary Config Service.
Protocols: gRPC/REST with ETag/If-None-Match, long-poll/watch, snapshots + incremental diffusions.
Caching: local snapshots with TTL and signature; atomic change (double buffering).
Sequence: strong (leader/quorum) vs eventual (edge/IoT). For critical systems - quorum + RA.
Global rolling: by regions/rings (ring-deploy), with a limit of simultaneous zones.

7) Configuration data migrations

• Expand: we introduce new fields with defaults, without breaking consumers.
• Migrate: backfills/converters (migration provider scripts, idempotency).
• Contract: remove the obsolete when all controllers are on the new version of the schema.
• Compatibility rule: old logic understands new, new - old in transition.

8) Policy, Compliance and Security

Policy-as-code: Rego/Conftest/OPA Gatekeeper - prohibitions of dangerous values ​ ​ (for example, 'timeout = 0', disabling TLS, unlimited quotas).
RBAC/ABAC: who can change which sections and on which layers.
Four-eyes for sensitive segments (payments/limits).
Secrets: we keep out of common configs (KMS, Vault, SOPS), in the config - only links/references.
Signatures and trust: verification of deliveries (attestations), prohibition of unsigned snapshots.
Sanitizing: protection against injection in templates and during rendering.

9) Observability, SLO and risk management

Config tags in telemetry: '{config _ digest, config_version, ring, scope}' in logs/metrics/tracks.
Golden metrics of config guns: application time, success rate, number of rollbacks, consistency time.
Gates when rolling configs: as for code - canary steps and auto-stop for SLO degradation.
Dogfooting: internal/beta cohort first.

10) Hot-reload, transactionality and security of application

Atomic switch: A new configuration is being prepared in memory → a single atomic switch.
Dry-run: we validate and simulate application (including field/policy conflict).
Partial failure: an all-or-nothing strategy for related components or a clear description of degradation.
Backoff/Retry: on application error - safe rollback and repeat with exponential delay.

11) Ficheflags as a subset of configs

Ficheflags are config data with special policies: segment targeting, inclusion radius restrictions, kill-switch.
Requirements: deterministic targeting semantics, auditing, secure defaults, client/server version compatibility.

12) Tools and media

Media: JSON/YAML/TOML/Protobuf/Avro (for network delivery - more often Protobuf/JSON).
Render/composition: Kustomize/Helm/Jsonnet (like generators, but the result is clean data).
Storages/buses: Git, OCI registers (as artifacts), S3-compatible storages, etcd/Consul/KV.
Controllers: proprietary operators, GitOps agents, Sidecar config providers.
Policy: OPA/Rego, Kyverno-like mechanisms.

13) Checklists

Design

• Scheme comes first (JSON Schema/Proto), types/restrictions/defaults are described.
• Schema versioning and migrations are documented.
• Layer hierarchy and merge strategy defined and tested.

Pipeline

• Lint → schema-validate → semantic tests → policy-check → sign → publish.
• Dry-run and effective-config visualization for reviewers.
• Canary rolling of configs with auto-gates via SLO.

Prod

• There is a'config _ digest' in the logs/metrics.
• Configuration rollback - the same button as the code deposit.
• Configs snapshots/backups and audit history are available and verified.

14) Frequent anti-patterns

The imperative in the config: conditions/scripts/templates with logic are not validated and unpredictable.
Mix secrets and shared settings in one file/repository.
Opaque merge: It's unclear where the bottom line came from.
Lack of a scheme: "everything is valid" ⇒ bugs on sale.
Global Ring/Canary Free Edits: Instant Degradation for All.
Drift of surroundings: manual edits in runtime past the source of truth.
Long TTLs in config cache without forced disabled mechanism.

15) Scenarios (sketches)

A. Fine-tuning traffic limits by region

1. PR with changes' RateLimitPolicy'to' ring-0 '(internal clients).
2. AutoChecks schema/policy (2k rps ≤ limit).
3. Promotion on 'ring-1' (5% of users), monitoring p95/error rate.
4. Expanding to 'ring-N', fixing a snapshot, closing a task.

B. Updating the tariff schedule (financial settings)

strong semantics and business policies: double review, two-stage promotion, time-window entry, auditing and instant rollback capability.

C. Global payment fifflag config flag with kill-switch: targeting "employees → beta → 10% → 100%," automatic stop when successful payment rate falls below the threshold.

16) Integration with Zero-Downtime and Progressive Delivery

Config canaries are synchronized with release rings.
Version compatibility: first expanding fields, then code, then tightening.
Shadow configs: parallel calculation of solutions (for example, limiting) for comparison with combat.

17) Summary

The configuration-as-data approach transforms settings from fragile files into robust domain models with clear contracts, validation, and policies. This is the basis of predictable rolling, safe experiments and quick reaction to incidents. Formalize schemes, separate secrets, implement GitOps and canary config pooches - and configuration will cease to be a risk, becoming a managed platform asset.