# Candidate deployment matrix (Proposed)

No costs, throughput, latency, geographic guarantees or completed deployments are claimed. Platform references checked 2026-10-11; recheck limits before implementation choices.

Two distinct queues: the internal **resolution-job queue** and the **product-ingestion queue**. Both carry small payloads that reference persisted evidence; durable processing survives an HTTP request ending. The resolver owns database writes and schemas; durable state never lives in a Worker process. Hyperdrive connects to an existing PostgreSQL database; it is not the storage service. Cloudflare placement is not a guarantee of the country a merchant sees.

| Component | Candidate | Status | Responsibility | Dependencies | Portability | Constraints | Cost drivers | Validation question |
|---|---|---|---|---|---|---|---|---|
| Simple HTTP/API collectors | Cloudflare Workers with Cron Triggers ([docs](https://developers.cloudflare.com/workers/configuration/cron-triggers/)) | PROP | Fetch APIs/feeds on a schedule; submit captures | Resolver intake; source credentials (secrets) | High — same SourceCollector.collect runs as a Node process | Request duration and subrequest limits; cron granularity | Invocations, CPU time | Do the largest feeds fit within one invocation, or must collection paginate across runs? |
| Browser-dependent collectors | Cloudflare Browser Run or local browser automation ([docs](https://developers.cloudflare.com/browser-run/faq/)) | PROP | Render JS storefronts; screenshots | Resolver intake; R2 via intake | Medium — Puppeteer/Playwright code ports; session limits differ | Concurrent sessions and session duration | Browser time | Which sources truly need rendering, and how many pages per run? |
| Collection requiring known egress | Local process or regional host with verified outbound geography ([docs](https://developers.cloudflare.com/workers/configuration/placement/)) | PROP | Collect geo-gated storefronts | Host operator; heartbeat endpoint | High | Verification of egress country is our responsibility | Host rental | Which sources actually gate by visitor country? |
| Resolver intake + admin API | Cloudflare Worker ([docs](https://developers.cloudflare.com/queues/reference/how-queues-works/)) | PROP | Validate, store receipts, enqueue jobs, admin endpoints | R2, Queues, Hyperdrive | Medium — HTTP handler is portable; bindings are not | Request ends before processing completes → durable queue + DB | Requests | Body sizes: inline small artifacts or always upload to R2 first? |
| Parsing, matching, LLM jobs | Queue-driven Worker consumers ([docs](https://developers.cloudflare.com/queues/reference/how-queues-works/)) | PROP | Bounded processing steps | Resolution job queue, R2, Hyperdrive, LLM provider | Medium | Message size → pass references; retries and dead-letter handling | Messages, CPU, model tokens | What fraction of captures fall back to LLM? |
| Raw evidence | Private R2 bucket ([docs](https://developers.cloudflare.com/r2/)) | PROP | Store HTML, JSON, screenshots by checksum | — | High — S3-compatible API | Retention policy (DEC-06) | Storage, operations | Artifact volume per month at target coverage? |
| Canonical state, cases, outbox | Managed PostgreSQL via Hyperdrive ([docs](https://developers.cloudflare.com/hyperdrive/)) | EST | Facts, mappings, review cases, decisions, outbox | External PostgreSQL provider | High | Hyperdrive connects to an existing DB; it is not storage | Database plan | Which provider/region relative to Workers placement? |
| ↳ alternative | D1 (SQLite semantics) ([docs](https://developers.cloudflare.com/d1/)) | OPEN | Same as above if chosen | — | Low — SQLite dialect, Cloudflare-specific | Schema, query, transaction and capacity validation required | Rows read/written, storage | Can outbox-in-transaction and JSON queries be reproduced within limits? |
| Product service | Separately deployed Worker ([docs](https://developers.cloudflare.com/queues/reference/how-queues-works/)) | PROP | Inbox, projections, search, shipping evaluation | Product-ingestion queue; its own projection store (OPEN) | Medium | Owns projections; never writes resolver schemas | Requests, storage | Projection store choice for search/filter workloads? |
| Operator frontend | Workers static assets on an access-controlled admin origin ([docs](https://developers.cloudflare.com/workers/static-assets/)) | PROP | Review, collectors, improvements, contracts | Resolver administrative API only (authenticated) | High | Never calls the product API for operator decisions; operator endpoints are sensitive | Requests | Operator auth mechanism (identity-aware proxy vs session)? |
| Consumer frontend | Workers static assets on a public origin ([docs](https://developers.cloudflare.com/workers/static-assets/)) | PROP | Search, comparison, shipping answers | Product API only (read-only) | High | No access to resolver administrative API | Requests | Caching policy for applied projections? |

## References

- placement: https://developers.cloudflare.com/workers/configuration/placement/
- cron: https://developers.cloudflare.com/workers/configuration/cron-triggers/
- browser: https://developers.cloudflare.com/browser-run/faq/
- hyperdrive: https://developers.cloudflare.com/hyperdrive/
- d1: https://developers.cloudflare.com/d1/
- queues: https://developers.cloudflare.com/queues/reference/how-queues-works/
- r2: https://developers.cloudflare.com/r2/
- static: https://developers.cloudflare.com/workers/static-assets/