Data Platform¶
Purpose¶
Architecture-level view of D1 and R2. Operational commands (querying, backup, troubleshooting) live under Cloudflare → D1/R2 and Operations - this page is about shape, not commands.
D1: akshaya-group-global¶
One database, binding name DB everywhere it appears. Not exclusive to the central API
Worker - corporate-web, software-web, and admin-web each declare their own d1_databases
binding to this exact same database/database_id in their own wrangler.jsonc, because their
own Worker code (the /customer-portal*, /freelancer-portal*, and admin routes) reads/writes
D1 directly rather than calling the central API. logistics-web, commerce-web,
embroidery-web, and investors-web (no run_worker_first, pure static assets) have no D1
binding at all - verified by checking every app's wrangler.jsonc directly, not assumed.
Migrations (9, all additive-only)¶
| # | File | What it adds |
|---|---|---|
| 0001 | 0001_initial.sql |
contacts table (the corporate contact form) |
| 0002 | 0002_freelancer_network.sql |
freelancer_applications |
| 0003 | 0003_customer_portal.sql |
customer_profiles |
| 0004 | 0004_unified_auth.sql |
users (unified auth across customer/freelancer surfaces) |
| 0005 | 0005_freelancer_marketplace.sql |
Extends freelancer_applications - freelancer marketplace foundation |
| 0006 | 0006_freelancer_structured_skills.sql |
New structured-skills table alongside the existing free-text field |
| 0007 | 0007_customer_freelancer_shortlist.sql |
Customers can shortlist a public freelancer profile |
| 0008 | 0008_customer_requirements.sql |
Customers can create marketplace requirement briefs |
| 0009 | 0009_freelancer_requirement_invitations.sql |
Customers can invite a freelancer to a requirement |
docs/DEPLOYMENT.md previously described these as "0001-0005", which went stale once 0006-0009
were added. Fixed in fix/platform-hardening: §5 now describes running every ordered file in
workers/api/migrations/ rather than a hardcoded range, so it stays correct as more are added,
instead of citing a specific count here that would just go stale again. All 9 migrations listed
above, including 0006-0009, follow the same additive-only discipline (CREATE TABLE IF NOT
EXISTS, new tables/columns only, never a DROP/rename/type change) that docs/DEPLOYMENT.md §5
explains is what makes rollback safe at all.
Schema evolution pattern¶
Every migration after 0004 is explicitly commented as additive-only, several naming their product
phase (Phase 1/Phase 2 Task N) - a real, followed convention in this codebase, not just a
one-off rule written in docs/DEPLOYMENT.md.
R2: akshaya-group-global-files¶
One bucket, binding name FILES everywhere it appears. Same story as D1 -
corporate-web/software-web/admin-web each bind directly to this same bucket alongside the
central API Worker; the 4 pure-static apps have no R2 binding. In the API Worker specifically,
env.FILES is used for freelancer reference-image upload/retrieval/delete (.put/.get/.delete
keyed by a generated reference key) - see Cloudflare → R2.
Email: Cloudflare Email Workers (send_email binding)¶
Not D1, not R2, but part of the same API Worker's data-adjacent bindings - NOTIFY_EMAIL sends
notifications to one configured address, with a fixed allowlist of sender addresses (one per
app-facing form: software, logistics, commerce, embroidery, support, freelancers). See
Cloudflare → Workers for the binding detail.