Architecture overview

A Spikefrost app is a Cloudflare Worker with four kinds of state attached, deployed to a global network on every release. This page is the map; the rest of this section drills into each part with the reliability, durability, and recovery detail an architecture review needs.

The shape matters more than the parts. A cache hit never reaches your code: no isolate starts, no query runs, no cost is incurred. A miss runs your Worker in the location nearest the user, which then reaches state through bindings. Understanding which requests take which path is most of what performance and cost tuning is on this platform.

The four primitives

Primitive	What it is	Use it for	Consistency
Worker	A V8 isolate running your code	All request handling	Stateless per request
D1	A SQLite database, primary plus optional read replicas	Business records, anything queryable	Strong at the primary; replicas may lag unless you use a session
Durable Object	A single-threaded object with its own SQLite storage	Live shared state and strict per-key ordering	Serialized — one writer at a time, by construction
KV	A key-value store	Cached values, flags, sessions	Eventually consistent (seconds)
R2 / assets	Object storage behind the CDN	Files, media, generated documents	Read-after-write for new objects

Choosing between them is a design decision with real consequences, covered in Choosing a data store.

What you operate, and what you don't

This is usually the first question in a platform review, so plainly:

	Who operates it
Server provisioning, patching, scaling, capacity planning	Nobody — it doesn't exist. No instances, no clusters, no autoscaling groups
Region selection, multi-region replication of compute	Automatic. Every deploy is global
TLS certificates, DDoS absorption, WAF	Platform, including for your custom domains
Database provisioning, backups, point-in-time recovery	Platform provides it; you decide retention posture and run the drills
Your application code, schema, and migrations	You (with an agent's help)
Your app's authorization rules and data model	You — nothing else can

The trade you're making: you give up control over where and on what your code runs, and in exchange there is no runtime infrastructure to operate, no patch cycle, and no capacity planning. For most enterprise applications that is a good trade. For workloads needing long-running processes, GPUs, or specific residency guarantees, it isn't — say so early and we'll tell you honestly whether this fits.

Isolation boundaries

Three boundaries are worth having clearly in mind, because they answer different questions:

• Between apps — separate Workers, separate databases, separate storage. One app has no path to another app's data.
• Between environments of one app — separate databases, KV namespaces, object state, and metrics datasets. Staging cannot read production rows. See Environments.
• Between tenants of the platform — your code runs in a V8 isolate, the same mechanism browsers use to separate origins. This is strong memory and execution isolation, and it is not dedicated single-tenant hardware. The distinction matters in a security review, so Isolation and tenancy treats it properly rather than sloganeering.

The boundary that decides your resilience design

The single most consequential fact on this page:

Cloudflare commits to a 99.99% monthly uptime SLO for Workers — the compute path. That SLO explicitly excludes the availability of storage bindings: D1, Durable Objects, KV, and R2.

So compute and state do not fail together, and they are not guaranteed together. An application designed as though "the platform is up or down" is designed against a model that doesn't exist here. One designed to degrade — serving cached and static content when a binding is slow, queueing writes rather than dropping them — stays useful through events that would otherwise be outages.

That's not a caveat buried in a contract; it's the central design input. Failure domains and resilience works through it, and SLAs, limits and quotas quotes the commitments and exclusions in full.

Where to go next

Read in order for the full picture:

1. The life of a request — what happens in the milliseconds after a click.
2. Compute and isolates — what executes your code, and its limits.
3. Choosing a data store — where state belongs.
4. Consistency and correctness — the guarantees, and how to avoid lost updates.
5. Durability, backup and recovery — RPO, RTO, and restore drills.
6. Failure domains and resilience — blast radius and graceful degradation.
7. Change management and rollback — how releases ship and unship.
8. Observability and audit — what's recorded, and for how long.
9. Isolation and tenancy — the security-review answers.
10. SLAs, limits and quotas — the reference tables.