SveltyCMS employs a Svelte 5 Runes-based state machine to manage the application lifecycle, enforce security boundaries during bootstrap, and recover autonomously from failures.

1. System States

2. Reactive State with Svelte 5 Runes

The system state is managed by SystemStateContainer (src/stores/system/state.svelte.ts) using $state and $derived runes:

1. Zero-Tax Access: Direct system.state reads — no get() helper overhead
2. Fine-Grained Reactivity: Components re-render only when the specific service they watch changes
3. Derived Intelligence: overallState is a $derived rune — zero computation when idle
4. Hot-Path Cache: isSystemReady() uses a module-level cache invalidated only on state transitions — zero-overhead for handleSystemState and all downstream hooks
5. Single Source: Consolidated in state.svelte.ts — no dual-state file duplication

3. Phased Initialization

Instead of a monolithic boot, the system targets “Minimum Viable Services” based on request intent:

Thundering Herd Prevention: Only the first request triggers initialization. Subsequent requests wait on the shared dbInitPromise — preventing connection storms.
Zero settling delay: plugin-registry.ts and db-init.ts have no setTimeout between CORE and WARMED. Proxy registrations are synchronous; ready plugins boot in parallel as soon as dependencies are met.
Logical vs. Technical: Lazy Holders enforce physical code isolation, preventing server-only modules from leaking into client bundles.

4. Request Gating Middleware

handleSystemState (src/hooks/handle-system-state.ts) intercepts every request:

1. Fast-Path Resolution: Static assets, health checks, .well-known/ paths bypass immediately
2. Bootstrap Host Validation: During restricted states, only authorized hosts (localhost, ORIGIN, or Demo) can access bootstrap routes — prevents SSRF and DNS rebinding during setup
3. Setup Completion Gating: After setup completes, all /api/setup endpoints return 403 — enforced at both middleware and handler levels
4. Initialization Wait: Non-bootstrap requests pause while INITIALIZING (or timeout at 60s → FAILED)
5. State-Specific Blocking: Returns 503 with state-specific messaging for SETUP, FAILED, and RECOVERY states
6. Degradation Injection: If DEGRADED, injects locals.degradedServices for UI awareness

5. Self-Healing Watchdog

The Autonomous System Watchdog (src/services/system/watchdog.ts):

6. Route Resource State Machine & Cache Synergy

The Route Resource State Machine (src/services/core/route-resource-state-machine.ts) classifies every URL into precise operational resource profiles in < 10 microseconds, orchestrating with CacheService (src/databases/cache/cache-service.ts) for sub-millisecond route latency:

Cache Service Integration

• Adaptive TTLs: Configured per category in CATEGORY_TTL_SECONDS (schema: 3600s, setting: 1800s, content: 120s, api: 30s).
• Targeted Tag Invalidation: When database mutations occur, cacheService.invalidateTag(collection) purges only the modified collection’s cache entries without affecting other route lanes.
• Negative Bloom Cache: Bypasses dead DB lookups for non-existent records in < 1µs.

7. SvelteKit Remote Functions & Offline Resilience Engine

The Offline Draft Sync Engine (src/utils/offline-draft-sync.ts):

1. SvelteKit Remote Functions & Progressive Enhancement: Wraps Remote Function calls (wrapRemoteFunction) with optimistic Svelte 5 $state updates and graceful fallback on cellular drops.
2. Persistent Local Storage Drafts: Automatically saves in-progress form inputs via saveLocalDraft(collection, entryId, data, tenantId) so edits survive page reloads or device restarts.
3. Replay Handler Registry & Background Sync: Registers RPC handlers (registerHandler) and automatically replays pending mutations upon reconnection (window.addEventListener("online")) in FIFO order with exponential retry management (MAX_SYNC_RETRIES = 3).
4. Draft Cleanup & Conflict Protection: Clears local storage drafts (clearLocalDraft) only upon verified database transaction commit, preventing data loss on flaky edge connections.

8. Hardware-Aware Rate Limiting

The SystemMonitor utility (src/utils/system-monitor.ts) adjusts request costs based on real-time pressure:

9. Boot Telemetry

Every phase is measured with performance.now() precision, exposed via health API and MetricsService:

10. Client State Architecture: $app/state vs. Rune Stores

To maximize resource efficiency and eliminate memory duplication, SveltyCMS separates state into two distinct tiers:

1. The Zero-Duplication Principle (page.data)

Server-loaded data (settings, user, theme, systemLanguage, contentLanguage, contentNodes, collectionSchema, entries, pagination) is delivered directly to components via $app/state (import { page } from '$app/state'):

• Zero Memory Duplication: Data is NOT mirrored into global client stores. Components read page.data.<key> directly.
• Zero Sync Effects: Eliminates $effect.pre and $effect loops that previously synchronized server loads into store singletons.
• SSR-Hydration Consistency: Ensures the rendered DOM matches the server payload byte-for-byte with zero hydration mismatch.

2. High-Performance Rune Stores (src/stores/)

Client stores are strictly reserved for transient, device-local, or cross-component UI state that does not originate from server loaders:

3. Resource-Saving Guidelines

1. Use $state.raw for large reference trees: Read-only data trees (such as complete schemas, public config, or static content hierarchies) use $state.raw instead of deep $state proxies. Deep $state wraps every nested property in a JavaScript Proxy; using $state.raw with immutable reference updates (this.state = { ...this.state, [key]: value }) reduces V8 heap allocation by ~60% on complex schema sets and completely eliminates proxy trap dispatch latency.
2. Never create legacy svelte/store bridges: Do not export .subscribe(), writable(), or derived() wrappers. Fine-grained Svelte 5 runes ($state, $derived, $props.id()) provide immediate direct access with zero event emitter overhead.
3. Use Native Reactive Collections: When tracking sets of items (such as active token IDs, translated field keys, or concurrent operation queues), use SvelteSet and SvelteMap from svelte/reactivity instead of plain arrays or generic objects. This provides $O(1)$ lookups and fine-grained change notifications without re-creating arrays.
4. Server-to-Client Zero-Copy Pipeline: Data loaded by server hooks and loaders (+layout.server.ts / +page.server.ts) is delivered directly into SvelteKit’s serialized payload. Client components read directly from $app/state (page.data), completely bypassing redundant client store singletons.
5. Direct-to-Wire Serialization: Bypasses intermediate object hydration across all 4 database engines (sqlite, postgresql, mariadb, mongodb), formatting JSON directly in the database driver or wire stream, saving GC cycles and reducing tail latencies (p95 < 0.5ms).
6. Keep single-consumer stores colocated: Feature-specific stores live alongside their UI component rather than in src/stores/ (e.g. plugins/cookie-consent/consent-store.svelte.ts, components/image-editor/image-editor-store.svelte.ts).

11. Incremental Service Refresh

reinitializeSystem performs surgical updates without destructive resets:

• Config Hot-Reload: Re-parses private.ts without dropping active DB connections
• Dynamic Settings Sync: Automatically re-synchronizes in-memory cache with database
• Zero-Downtime Transitions: Minimizes the blocked-request window during updates

Related

• Server Hooks
• Database Core
• API Security & Token Hardening
• Login Resilience & Recovery
• Behavioral Learning Engine — Starts/stops with server lifecycle during FULL phase
• Utility System Architecture — Complete utility reference: structure, patterns, import guide
• Store System Architecture — Complete store reference: patterns, purpose, page.data vs stores
• Sidebar States & UI Visibility — How panels, sidebars, and layout visibility are managed