Workers Architecture

The backend is split into four independent Cloudflare Workers that share the same D1 database and KV namespace.

Worker Matrix

Worker	Directory	Port (dev)	Routes
auth-worker	auth-worker/	8788	/api/auth/*, /api/users/*
billing-worker	billing-worker/	8789	/api/billing/*
listings-worker	listings-worker/	8790	/api/listings*
chat-worker	chat-worker/	8787	/api/chat/*, /api/ws, /api/search*

Shared Infrastructure

All workers read session tokens from the same KV namespace for auth validation. No inter-worker HTTP calls are needed — each worker queries D1 directly.

Session Flow

1. User logs in via POST /api/auth/login
2. auth-worker creates a session token, stores it in KV as session:{token}
3. Browser receives session={token}; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=604800
4. On subsequent requests, any worker reads session:{token} from KV to validate the user

CORS

All workers use the shared CORS helper from shared/src/cors.ts:

• Access-Control-Allow-Credentials: true
• Dynamic origin validation
• Automatic preflight handling

Auth Validation Pattern

Each worker follows the same pattern for protected endpoints:

1. Read Cookie: session={token} from the request
2. Look up session:{token} in KV
3. If found and not expired, extract userId
4. Query D1 for the full user record
5. Attach user to the request context for handlers

Deployment

Each worker is deployed independently:

cd auth-worker && npm run deploy
cd billing-worker && npm run deploy
cd listings-worker && npm run deploy
cd chat-worker && npm run deploy

This means you can ship a billing fix without redeploying chat or auth.