Compressing Feature Flags and Config Records at the Edge

Read on Every Request

Feature flags and configuration records have an unusual cost profile: they are small, but they are read constantly. A flag set checked on every page load, a config blob fetched on every cold start — these reads dominate the cost of the data far more than its storage at rest.

Small and Structured

A flag record is a perfect smoltext payload:

{"new_checkout":true,"beta_ui":false,"max_items":50,"region":"us-east","tier":"pro"}

Around 82 bytes. It is structured, low-entropy, and highly repetitive across users — the keys are identical for everyone, and the values draw from a small vocabulary. The trained codebook and dictionary deflate collapse this efficiently.

Why Read-Heavy Changes the Calculus

For most data, storage and read costs are comparable. For flags and config, reads can be orders of magnitude more frequent than writes. That means the read-egress savings from compression — smaller bytes transferred on every fetch — dominate the benefit. Compress once on write, save on millions of reads.

The Pattern

1. On config publish, compress the record via https://api.smoltext.sprapp.com/v1/compress.
2. Store the compact form in your edge KV or config store.
3. On read, decompress before evaluating flags.

Because compression and decompression are sub-millisecond at the edge, the flag-evaluation hot path stays fast.

Caching the Decompressed Form

For extreme read rates, decompress once per worker instance and cache the plain object in memory. You pay decompression on cold start, then evaluate flags from the in-memory copy. This combines storage savings at rest with zero decompression cost on the hot path.

Versioning Flags

Keep a version marker on the compressed record so a worker can tell compressed from legacy formats during rollout. This lets you migrate gradually without a flag-day cutover.

What Stays Raw

If a config record grows large — a big allowlist, an embedded ruleset — reconsider. Large config is better served by a general compressor. smoltext targets the small flag-and-setting records that make up the bulk of high-frequency config reads, not large bundles.

Measuring the Win

Because reads dominate, model the savings on read volume, not storage. Take your flag-fetch rate, multiply by the byte reduction per fetch, and apply your per-byte read rate. For high-traffic applications, the read-egress savings on a compressed flag set add up quickly — and the integration is a thin wrapper around your existing config layer.