Back to Portfolio

Content Management and Delivery System

Executive Summary

In this case study I will explain the engineering and architecture of a custom, full-stack Content Management and Delivery System. Built for a freelancing contract. The system was created to simplify internal content ingestion workflows, and optimize global content delivery with as low latency as possible. As the sole architect on this project, I was responsible for the end-to-end implementation, focusing heavily on client-side caching optimizations, lightweight data storage, and efficient data delivery.

The Technical Challenge

The purpose was to build a robust and capable system for handling a lot content while maintaining high performance.

  1. An Admin Panel: A secure and intuitive dashboard for managing, and organizing content.
  2. User Facing Panel: A panel to list all of this content capable of filtering based on existing criteria, or free-form search, while serving content assets to end-users without overloading the servers.
  3. Bandwidth Optimization: The initial architectural scope anticipated a high volume of concurrent users making frequent data requests. The client facing interface required a mechanism created to prevent users from constantly downloading unchanged content, mitigating potential bottlenecks in bandwidth, and database read costs under heavy loads.

Technology Stack Selection

Because I had complete and utter decision freedom, I selected a bleeding-edge and modern tech stack chosen specifically for scalability, performance, and type safety:

  • Frontend: SvelteKit, I have chosen it to build a dynamic and hyper responsive website while leveraging small bundle sizes, and the built-in SSR.
  • Runtime Environment: Bun, Used as primary runtime and package manager to maximize execution speeds.
  • Database & Storage: Google Cloud Firestore & Firebase Object Store, Using the flexible NoSQL document database for rapid querying, paired with Firebase Object Store to securely host and stream content file assets.
  • Schema Validation & Type Safety: Typescript, ArkType Used ArkType's sub 50ns runtime validation engine to enforce strict data structures for content payloads before any data hit the database.
  • Hosting & CDN: Vercel & Cloudflare, Deployed on Vercel for optimized hosting infrastructure, and Cloudflare as CDN to handle specific content assets caching.

Core Architecture & Features

Delta-Sync Optimization

To ensure client-side performance was fast, I designed a custom delta-sync engine to sync the browser's local cache with the database efficiently.

  • The Changes Table: Instead of forcing the client to download entire already existing data that only changed by a little bit on every refresh, I implemented a separate dedicated table in Firestore. This table tracked changes and applies them if those records already exist in the browser's cache.
  • Differential Payloads: When a user loaded the application, I fetched the user's existing delta and fetched only the changes after it and merging it locally in the browser. This reduced API payload sizes.

User Experience & Data Integrity

Instead of overloading the system with heavy, server-side metadata, I built a pragmatic direct-to-storage ingestion flow.

  • Resumable Uploads: I used Firebase's native uploadBytesResumable SDK function on the client side, so that large assets uploads survive any interruptions without failing.
  • Decoupled Asset Mapping: Files were uploaded clearly to Firebase Storage with a basic identifier, which was attached to the corresponding document in Firestore.

Edge Delivery

Cloudflare was integrated specifically to intercept and cache high-bandwidth file assets like images. By caching those static items, the application minimized latency for client-facing views.

Retrospective & Architectural Evaluation

Design for Anticipated Scale: The custom delta-sync system was proactively created to sustain high database reads, to lower rereading when data already exists in the user's cache and to lower read costs under heavy loads. Once deployed in production, the actual real world usage was significantly lower than what we expected.

The Takeaway: While the custom caching layer worked, the lower real-world volume means that the existing OOTB Firestore cache strategies would have been sufficient. This project served as a valuable lesson in balancing proactive engineering for scale against immediate data, showing that simpler implementations are often the most correct choice for standard traffic loads.

Key Takeaways

The project proved to me that you for most of the time don't need to over-engineer some solutions, and what comes out of the box is usually enough. But regardless, by combining Svelte with a custom delta-sync mechanism, direct Firebase storage streaming, and Cloudflare's edge caching, the application achieved speed and reliability, while keeping the codebase generally lightweight and maintainable.