Edge Computing

Authrim is an edge-native Identity & Access Platform for Cloudflare Workers. Login, token exchange, session validation, federation, and management surfaces are split across Workers and connected with Service Bindings. This page explains why edge-native deployment matters for identity, how Authrim uses Workers-native primitives, and what performance and cost characteristics operators should evaluate.

Why Edge for Identity?

Traditional identity platforms run on centralized servers in one or a few regions. This creates inherent limitations:

Challenge	Centralized Approach	Edge Approach
Latency	Extra round trips to a fixed region	Workers can execute close to users or close to storage depending on workload
Cold start	Container/VM startup can add delay	V8 isolate startup is lightweight
Scaling	Vertical scaling or complex auto-scaling	Automatic horizontal scaling per-request
Single point of failure	Region outage can affect the whole service	Requests can be routed across Cloudflare’s global network
Global users	Distant users depend on central regions	Deployment can use global Workers plus explicit storage/residency profiles

Authentication is on the critical path of every user interaction. A slow login flow or token validation directly impacts user experience and application performance. Edge-native deployment reduces avoidable routing overhead, but actual latency still depends on workload shape, storage profile, Cloudflare plan limits, and network path.

Cloudflare Workers Platform

Authrim runs on Cloudflare Workers, a serverless platform with unique characteristics:

V8 Isolates (Not Containers)

Workers execute in V8 isolates — the same JavaScript engine used by Chrome. Unlike containers or VMs:

• Lightweight startup — isolate startup is generally much lighter than container startup
• Small runtime footprint — Workers avoid managing container images and VM fleets
• Secure — hardware-level isolation between tenants

Global Distribution

Workers run on Cloudflare’s global network. Authrim uses this for public protocol endpoints while keeping storage placement explicit through D1 bindings, runtime storage profiles, tenant-D1 routing, external database adapters, and Durable Object location hints where applicable.

Platform Primitives

Authrim leverages the full Workers ecosystem:

Primitive	Usage in Authrim
Workers	Stateless request processing (auth flows, token validation)
Durable Objects	Hot strongly consistent state (sessions, auth codes, challenges, PAR, DPoP, device/CIBA, SAML, flow state)
D1	Deployment and tenant databases (DB, DB_PII, DB_ADMIN, generated tenant-D1 slots)
KV	Generated configuration, cache, consent cache, tenant runtime registry snapshots
Service Bindings	Inter-worker communication (zero-network-cost RPC)
Queues	Async processing (webhooks, SCIM sync, audit log export)

Stateless Workers + Stateful Durable Objects

Authrim’s architecture cleanly separates concerns:

flowchart TB
    subgraph Stateless["Stateless Layer — Workers"]
        w1["Request routing"]
        w2["Token signing"]
        w3["OIDC validation"]
        w4["Policy eval"]
        w5["Claim mapping"]
    end
    subgraph Stateful["Stateful Layer — Durable Objects"]
        do1["Session storage"]
        do2["Auth code lifecycle"]
        do3["Challenge state"]
        do4["Refresh tokens"]
        do5["Rate limit counters"]
    end
    Stateless -- RPC --> Stateful
    Stateless --> D1["D1 (SQL)"]
    Stateful --> DOS["DO Storage (per-shard)"]

Workers handle stateless computation — parsing requests, validating tokens, evaluating policies, constructing responses. They scale horizontally with zero configuration.

Durable Objects handle stateful operations — storing sessions, managing auth code lifecycle, enforcing rate limits, and maintaining protocol state. Each DO instance is a single-threaded actor with strongly consistent storage, scaled by explicit shard settings where supported. See Architecture — Durable Object State and Sharding.

This separation lets the stateless layer scale with Workers while the stateful layer scales through explicit Durable Object sharding and storage profile choices.

Performance Characteristics

Measured under K6 Cloud load tests against representative Authrim workloads:

Metric	Value	Notes
Token-oriented endpoints	2,500–3,500 RPS	Tested token/introspection-style workloads
Full OAuth login flow	~150 logins/sec	Representative login workload
Worker CPU time	1–4ms typical	Observed in tested runs
Error rate	0% in tested runs	For the measured scenarios

Note

These figures are not a production capacity guarantee. Actual performance depends on workload shape, Cloudflare plan limits, D1/KV/DO behavior, storage profile, tenant-D1 routing, external database latency, and logging/audit settings.

Why Latency Still Matters

Identity operations sit in login, token refresh, API authorization, and federation paths. Authrim’s architecture reduces avoidable network hops by keeping protocol workers close to the request path and by using Service Bindings for worker-to-worker calls. Storage-heavy paths still need capacity planning around D1, Durable Objects, tenant-D1, external databases, and audit sinks.

Scaling

Horizontal Scaling

Workers scale automatically — Cloudflare instantiates as many isolates as needed to handle incoming requests. No provisioning, no capacity planning.

For Durable Objects, Authrim uses explicit shard counts for high-traffic auth state such as sessions, authorization codes, refresh token rotation, and challenges. See Architecture — Durable Object State and Sharding for details.

The result:

flowchart TB
    req["Incoming requests"]
    req --> W1["Worker 1"] & W2["Worker 2"] & WN["Worker N"]
    W1 & W2 & WN --> DO0["Session shard 0"] & DO1["Session shard 1"] & DO2["Auth code shard 0"] & DO3["Refresh shard 0"]

Placement and Storage Locality

Authrim separates compute placement from storage selection:

• Worker routing is handled through ar-router and Service Bindings.
• Storage locality is selected through runtime storage profiles (shared-d1, tenant-d1, external database profiles).
• Durable Object locationHint can guide initial placement, but it is not a latency guarantee.
• Tenant-D1 deployments must plan generated tenant database slots, migrations, and registry snapshots.

Cost Efficiency

Authrim has no per-user vendor fee, but it is not free to operate. Cloudflare usage and operational requirements drive the cost.

Cost Driver	What Affects It
Workers	Request volume, CPU time, worker count, deployment profile
D1 / tenant-D1	Read/write volume, database count, tenant slot count, storage size
KV	Cache reads/writes, generated config, tenant runtime registry snapshots
Durable Objects	Hot state requests, storage, shard counts
R2 / logging sinks	Audit retention, archive policy, export volume
Operations	Monitoring, security review, compliance, support, backups, incident response

Note

Use the homepage calculator only as an infrastructure-cost reference. It excludes compliance, monitoring, support, operations, security review, external databases, and large R2/archive usage.

Edge vs. Traditional — Summary

Aspect	Traditional (Central)	Authrim (Edge)
Latency	Depends on chosen region and distance	Depends on worker routing, storage profile, and network path
Cold start	Container/VM startup may add delay	Workers isolate startup is lightweight
Scaling	Manual / auto-scale (minutes)	Automatic (milliseconds)
Regions	Explicit provisioned regions	Cloudflare global network plus explicit storage/residency choices
Cost	Vendor and infrastructure model dependent	Cloudflare usage plus Authrim operational costs
Ops burden	Servers, scaling, patching, certs	Cloudflare-managed primitives, with Authrim deployment and compliance operations still required
Data locality	Limited by region choice	Runtime storage profiles, tenant-D1, external DB profiles, and location hints
Availability	Region-bound architecture	Depends on Cloudflare services, deployment design, and storage profile

Next Steps

• Architecture — System design, database abstraction, and DO sharding details
• Identity Hub — Unified identity federation concept