# Platform Limits

> Check Cloudflare Developer Platform hard limits and runtime constraints before implementation: Worker memory/CPU/body/protocol constraints, D1 size/query limits, Durable Object hotspots, KV consistency, Queue message size/order, R2 object flows, and product availability. Use to prevent invalid designs.

- Skill: `zllovesuki/platform-limits` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zllovesuki/platform-limits`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zllovesuki/platform-limits/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zllovesuki (https://skillmd.com/u/zllovesuki)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zllovesuki/platform-limits

---

# Platform Limits

Use this skill before committing to an implementation. The exact numbers can change, so verify current limits in official Cloudflare docs for the product and plan.

## Limit-check workflow

For each proposed architecture, write down:

```markdown
## Limit check
- Worker request duration/CPU/memory constraints:
- Request/response body size assumptions:
- Protocol requirements: HTTP, WebSocket, WebRTC, TCP/UDP, custom protocols:
- D1 database size/query/write assumptions:
- R2 object size and streaming assumptions:
- KV consistency and write/read volume assumptions:
- Queue message size, retry, and ordering assumptions:
- Workflow step/output/duration assumptions:
- Durable Object hot-key risk:
- AI model availability/token/context assumptions:
- Regional/data residency/compliance assumptions:
- Plan/account feature availability:
```

## Common constraint categories

- **Runtime shape**: Workers are not traditional servers; avoid native processes, arbitrary TCP servers, and long CPU-bound work.
- **Memory**: Do not buffer large files or huge query results; stream and paginate.
- **CPU**: Split heavy work into queues/workflows/containers when needed.
- **Consistency**: KV is eventual; Durable Objects and D1 patterns handle stronger consistency.
- **Hotspots**: One global Durable Object or one tenant-wide object can bottleneck.
- **Message size**: Queue messages should be small references, not payload dumps.
- **Database scale**: D1 should be modeled around boundaries and indexed query patterns.
- **AI**: Model catalogs, context windows, and pricing can change.

## Refactor when a limit appears

| Limit pressure | Refactor |
|---|---|
| Large file upload/download | Stream through Worker; store in R2 |
| Large export/report | Queue/Workflow + R2 result |
| High-contention update | Durable Object per entity |
| Huge relational dataset | Partition D1, use Hyperdrive/external DB, or rethink boundary |
| CPU-heavy transform | Chunk, queue, workflow, or container |
| Queue payload too large | Put payload in R2/D1 and send key/reference |
| KV consistency issue | Move source of truth to D1/DO |
| AI context too large | RAG/chunking/summarization |

## Code review red flags

- `await request.arrayBuffer()` on unbounded uploads.
- `SELECT *` without `LIMIT`.
- Queue message includes file contents or entire documents.
- Global mutable arrays/maps used as state.
- One Durable Object key named `global` or `main`.
- No pagination, streaming, or backpressure.
- Exact quota numbers hardcoded into business logic without config or documentation.

## Output requirement

If a limit might be relevant, mention it explicitly in the design or code review and include a mitigation. Do not silently assume Cloudflare behaves like a VM, container host, or regional database service.