Building a Real-Time Analytics Platform on Cloudflare Workers: An Edge-First Architecture

A developer who built a real-time analytics platform on Cloudflare Workers has published a detailed breakdown of the architecture. The design is explicitly edge-first, targeting sub-100 ms global event ingestion, real-time dashboards, and no cookies.

Overall architecture

The data flow is a simple three-layer structure:

1. A browser tracking script
2. A Cloudflare Worker built with Hono.js
3. Three persistence layers: KV, Workers Analytics Engine, and Supabase PostgreSQL

Dashboard updates are delivered over Supabase Realtime WebSockets. Because the code runs in V8 isolates, the usual cold-start problem of serverless functions is effectively absent, at under 5 ms.

Session management without cookies

To prioritize privacy, the system identifies sessions without using cookies or fingerprinting at all.

• session_id: generated with crypto.randomUUID() in sessionStorage, and disappears when the tab closes
• visitor_id: generated with crypto.randomUUID() in localStorage, and retained for 365 days

This approach tolerates roughly 5 to 15 percent overcounting in cases like private browsing or device switches, but that looks like a reasonable tradeoff if the goal is to avoid tracking individuals.

Performance optimization techniques

Deduplication

It uses a five-second deduplication window backed by KV. That prevents duplicate writes caused by reloads or temporary connection drops.

Controlling database load

Because writes to Supabase take 30 to 40 ms and become the main bottleneck, the system uses several optimizations:

• Aggregate multiple events into a single visitor record through upserts
• Use Math.max() to avoid race conditions from out-of-order updates
• Recompute ML value scoring only on every fifth heartbeat and when scroll or interaction state changes
• Double-write high-cardinality queries into Workers Analytics Engine to bypass Postgres

More efficient rate limiting

The KV write used for rate limiting was changed so that checks happen only when a 90 percent threshold is reached rather than on every request. That reportedly cut overhead by about 95 percent.

Real-time dashboard design

The dashboard uses a two-layer approach:

• Immediate data: KV counters show live visitor counts and clean themselves up automatically with a five-minute TTL
• Detailed updates: Supabase Realtime channels publish updates through PostgreSQL LISTEN/NOTIFY, with about 400 ms total latency

The dashboard uses Mapbox GL JS to place color-coded markers on a map based on each visitor’s value score.

Measured performance

Metric	Value
Event ingestion P95	47 ms (global)
Event ingestion P99	89 ms
Dashboard latency	About 400 ms
Cold start	Under 5 ms
Rate-limit accuracy	99.7%

Lessons from production

The article gives a fairly balanced account of both what worked and what did not.

What worked well:

• Hono.js provides an Express-like API without Node.js
• Cloudflare’s cf object gives free geolocation data and saves roughly 100 ms from external API calls
• KV’s eventual consistency is good enough for deduplication and rate limiting

What was painful:

• The official Supabase SDK depends on Node.js and does not run on Workers, so a custom PostgREST client had to be built
• KV write limits of 1,000 writes per second per namespace forced architectural changes
• Connection churn from stateless Workers to Supabase increased P99 latency

What the author would change next time:

• Use Workers Analytics Engine as the primary store from day one
• Use Durable Objects for strongly consistent live counts
• Batch Supabase calls into a single RPC operation

As a practical reference for building analytics infrastructure on edge computing, this is a useful architecture write-up.

How We Built a Real-Time Analytics Platform on Cloudflare Workers - DEV Community