How We Plan to Store 2.4 Billion Events on Cloudflare Workers

At Skala, our mission is to build a modern, edge-native fraud detection engine that scores every API event—whether it's a signup, payment, or login—and decides in 28ms at p99.

As we plan for global scale, our immediate design target is handling up to 2.4 billion events a month. Traditional origin database architectures (like Postgres or MySQL in a single cloud region) cannot meet this challenge due to global network round-trip latency. We are actively planning and prototyping a distributed storage layer directly at the network edge to keep data close to our users.

Why Cloudflare Workers & D1?

Cloudflare Workers run on V8 isolates rather than traditional containerized microservices. This provides two massive benefits: near-zero cold starts and a tiny memory footprint.

For storage, our blueprint pairs Cloudflare D1 with regional read-replicas. This will keep our telemetry data close to the client isolates, allowing us to query local configurations and user histories in single-digit milliseconds without routing back to a centralized cloud origin.

The Planned pipeline: Asynchronous Telemetry

Writing directly to a database during the path of a live API call is a major performance bottleneck. To hit our target of 28ms p99 latency, our edge nodes will decouple scoring from storage:

1. Check local cache: The worker looks up incoming request metadata (IP reputation, device fingerprints) against local KV caches.
2. Edge Evaluation: The worker evaluates threat models using optimized WebAssembly binaries in under 15ms.
3. Immediate Decision: The API returns a risk score (0-100) to the client immediately.
4. Buffer to Queue: The worker asynchronously pushes the telemetry logs to a Cloudflare Queue, preventing write lock delays.
5. Batch Write: A background consumer worker runs periodically, drains the queue, and writes logs to D1 in optimized batches for dashboard visualization.

Key Technical Challenges We Are Solving

As we build out this pipeline, we are actively tackling several technical constraints:

• Batching Strategy: Finding the sweet spot for queue batch sizes to avoid exceeding D1 transaction limits while maintaining near real-time updates.
• Edge Memory Footprint: Ensuring the telemetry logging logic doesn't inflate isolate memory consumption beyond Cloudflare's strict limits.
• CORS and Pre-flights: Optimizing edge headers to bypass pre-flight request round-trips for browser-initiated scoring calls.

By utilizing edge-native queuing and serverless databases, we plan to achieve the scale of 2.4 billion monthly events efficiently and affordably. We will share concrete performance metrics and code templates as soon as the first production trials go live.