When I added Workers KV to a Cloudflare Gateway allow-list tool, it was tempting to treat KV as the application’s primary database.

That would make the state model confusing because Gateway is the system actually enforcing the list.

I use a clearer split:

Cloudflare Gateway list = deployed enforcement state
Workers KV             = backup / recovery / sync metadata

The Worker periodically reconciles KV from the live list so changes made outside the application do not leave the backup permanently stale.

This also changes how errors should be handled. A successful KV write does not mean a policy change succeeded; the Cloudflare list update must succeed first and its outcome must remain authoritative.

The same principle applies to many automation systems: a cache or backup is useful only if it does not quietly become a second, conflicting source of truth.

Related: Managing Cloudflare Zero Trust Allow Lists with Workers and KV.