KwestKarz Photo Storage Specification - wwestlake/KwestKarz GitHub Wiki

KwestKarz Photo Storage Specification

Overview

This document defines the design and approach for storing photos and related media within the KwestKarz Internal Management System (IMS).

PostgreSQL remains the primary data store for structured business data. MongoDB will be used to store unstructured media content such as vehicle photos, documentation images, and any future large binary assets.


Purpose

  • Separate structured data (PostgreSQL) from large binary objects (MongoDB).
  • Improve performance, scalability, and flexibility for handling media.
  • Simplify data retrieval and storage patterns for media assets.

Storage Technology

  • Database: MongoDB
  • Usage: Dedicated to storing media assets (primarily images)
  • Storage Type: BSON documents with optional GridFS for very large files

Data Structure (MongoDB Document)

Each photo will be stored as a document in a collection called photos.

Example Document Structure:

{
  "_id": "uuid",
  "vehicleId": "uuid",        // Relational link to PostgreSQL Vehicle Id
  "uploadedBy": "uuid",       // User Id who uploaded the photo
  "timestamp": "2025-04-13T23:50:00Z",
  "filename": "front_left_fender.jpg",
  "contentType": "image/jpeg",
  "data": <binary image data>,
  "description": "Optional description or note"
}

Access Pattern

  • Upload photo:

    • Validate user permissions.
    • Insert document into MongoDB.
  • Retrieve photo:

    • Query by vehicleId or photoId.
    • Return as image stream for frontend display.
  • Delete photo:

    • Remove document by _id.

Integration Considerations

  • MongoDB connection string stored in configuration with appropriate security.
  • Photo metadata (vehicle association, uploader, timestamp) managed explicitly in MongoDB.
  • PostgreSQL only stores foreign reference (e.g., photo count or has-photos flag) if necessary.

Benefits

  • Clean separation of concerns between data types.
  • Optimized performance for media storage and retrieval.
  • Scalability for increased photo storage needs.
  • No unnecessary bloat in PostgreSQL.

Future Considerations

  • Optional use of MongoDB GridFS for files exceeding BSON size limits.
  • Possible extension to store PDFs, scanned documents, or other media types.
  • Automated cleanup or archival strategies for old or unused media.