# 7 — Cloudflare Edge Platform

**Rank 15 of 28** · Tier B · `app/workers/`, `app/GlobalCloudflareAdapter`, `app/BillboardGateway/worker`
**Stack:** TypeScript, Hono, Cloudflare Workers, D1, R2, KV, Durable Objects, Hyperdrive, WASM, Cloudflare Stream, wrangler

> **Why this ranks here.** Edge compute is genuinely differentiated experience —
> and the *constraints* are what make it interesting to a distributed-systems
> interviewer. No TCP sockets, no long-lived state, single-writer Durable
> Objects, and a cold-start budget. Every one of those forced a real
> architectural decision here.

---

## The fleet

| Worker | Role |
|---|---|
| `billboard_users` | 10.5K lines, 65 routes — library, playlists, feed, charts, Jamz matching |
| `billboard-feed-worker` | Feed API (was mock-only; identified and replaced) |
| `global_upload_service` | Media ingest, R2 multipart, `IngestDO` |
| `boxoffice-api` | Video catalog and moderation queue |
| `global_search` | Cross-mode search |
| `explore` | Discovery surfaces |
| `match_service` | Edge-side match endpoints |
| `storefront` | Commerce |
| `rpc_worker` | Service-to-service RPC |
| `array-media-service-manager-v2` | Media orchestration |

Plus `billboard-gateway-edge` — R2 **range streaming** for audio, with an
`/api/*` proxy to the Node origin.

## The interesting constraint

**Workers cannot open raw TCP sockets.** Not with a library, not with a shim.
That makes the Kafka wire protocol and CQL permanently unreachable from the
edge.

This is the constraint that produced the [Activity Graph](01-billboard-activity-graph.md)'s
outbox design: the Worker writes an event row transactionally, and a separate
host-resident Go process relays it into Kafka. The architecture is a *direct
consequence of a platform limit*, which is exactly the reasoning shape a
systems-design interview is looking for.

## Storage primitives, and what each is for

| Primitive | Used for | Why not the others |
|---|---|---|
| **D1** (SQLite) | Relational user/library data | Cheap, transactional, edge-local reads |
| **R2** | Audio/video objects, multipart ingest | No egress fees; range requests for streaming |
| **KV** | Config, hot lookups | Eventually consistent, so never for anything ordered |
| **Durable Objects** | Upload sessions (`IngestDO`), fingerprinting (`JamzFingerprintDO`) | Single-writer coordination — the only strong-consistency tool at the edge |
| **Hyperdrive** | Pooled Postgres from the edge | Connection pooling that Workers otherwise cannot have |

## WASM at the edge

`JamzFingerprintDO` loads **`kissfft.wasm`** — an FFT compiled to WebAssembly
to compute audio fingerprint constellations inside a Durable Object. (The
module was referenced but had never been built; building it was commit
`e04aaf6fb`.) The `emsdk/` and `chromaprint/` trees in `/srv` are the
toolchain and reference implementation behind it.

## Scope

| Metric | Value |
|---|---|
| Workers | 10 |
| Edge TypeScript | ~75K lines |
| Storage primitives | D1, R2, KV, Durable Objects, Hyperdrive |
| Notable | WASM FFT in a DO; R2 range streaming; multipart ingest |

## Interview surface this opens

- Durable Objects as a distributed single-writer primitive vs Raft/leases
- Eventual consistency in KV and why ordered data never belongs there
- Edge-to-origin patterns when the edge cannot speak your protocol
- Connection pooling for serverless (Hyperdrive) and the pool-exhaustion problem
- Range requests and byte-range streaming for media