Core Infrastructure

The core infrastructure layer provides the foundational components that all other systems build upon. This includes the multi-worker architecture, database abstraction, and per-property data isolation.

Overview

Broadford Living runs on Cloudflare's edge platform, using multiple Workers that communicate via service bindings and share data through D1 (shared state) and Durable Objects (per-property state).

┌─────────────────────────────────────────────────────────────────────┐
│                    Core Infrastructure                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    Workers Layer                             │   │
│  │                                                              │   │
│  │  bf_resident ────► Main API (properties, devices, users)    │   │
│  │  bf_auth ────────► Authentication and credentials           │   │
│  │  bf_notify ──────► Webhook ingress and event routing        │   │
│  │  bf_smart ───────► Smart device API abstraction             │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                              │                                       │
│                              ▼                                       │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    Storage Layer                             │   │
│  │                                                              │   │
│  │  D1 Database ────► Shared state (portfolios, properties)    │   │
│  │  Durable Objects ► Per-property isolated storage            │   │
│  │  R2 Storage ─────► Documents and backups                    │   │
│  │  KV Cache ───────► JWKS, AI analysis results                │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Key Components

Workers Architecture

The platform uses four primary workers, each with specific responsibilities:

Worker	Purpose	Key Bindings
bf_resident	Main API for property and device management	D1, DO, R2, Queues
bf_auth	Authentication, credentials, OAuth tokens	D1, KV
bf_notify	Webhook ingress from external platforms	Queues
bf_smart	Smart device API abstraction layer	External APIs

Workers communicate via service bindings, allowing type-safe RPC calls between workers.

Database Abstraction (sqlx-d1)

The sqlx_d1 crate provides a unified interface for both D1 and Durable Object SQLite:

• Compile-time query verification via sqlx macros
• Dual-target support for WASM (Workers) and native (tests)
• D1Connection for shared D1 database
• DOConnection for Durable Object SQLite

Per-Property Data Isolation

The UserDurableObject provides complete data isolation per property:

• Each property has its own SQLite database
• 50+ RPC request types for all operations
• WebSocket support for real-time updates
• Alarm API for scheduled tasks

Documentation

• Workers Architecture - Multi-worker design, routing, and bindings
• sqlx-d1 Patterns - Database abstraction and query patterns
• User Durable Object - Per-property storage and RPC protocol

Key Design Decisions

Why Multiple Workers?

Separation of concerns provides:

• Independent scaling and deployment
• Clear security boundaries
• Simpler codebase per worker
• Failure isolation

Why Durable Objects?

Per-property DOs provide:

• Complete data isolation (GDPR compliance)
• WebSocket connections tied to property
• Consistent state without distributed locking
• Automatic geographic placement

Why sqlx?

Compile-time SQL verification provides:

• Type-safe query results
• Early error detection
• IDE support for SQL
• Consistent patterns across D1 and DO