Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Deploying QuickDumpNow Dispatch Tool to Production: Job Tracking, CloudFront Rewrites, and Real-Time Status Management

This post documents a complete production deployment of the QuickDumpNow dispatch system, including infrastructure updates, job creation workflows, and CloudFront configuration changes necessary to support both the customer tracking portal and booking system.

What Was Done

We completed a multi-component production push for quickdumpnow.com that involved:

  • Updating CloudFront function logic to handle /book/ path rewrites alongside existing /track/ functionality
  • Creating a new job record for a customer (Mark) on Soderblom Avenue with complete tracking infrastructure
  • Promoting the QDN dashboard, track page, and booking pages from staging to production
  • Invalidating CloudFront cache distributions to ensure fresh content delivery
  • Resolving a tracking link validation issue where customers received "Job not found" errors

Technical Details: CloudFront Function Updates

The core infrastructure change involved modifying the CloudFront function at /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js. This function handles URL rewriting at the edge, transparently routing requests to origin-based resources without exposing backend paths to end users.

Why this approach: CloudFront functions execute at edge locations with sub-millisecond latency, making them ideal for request transformation. Rather than implementing rewrite logic in Lambda@Edge (which adds ~50ms latency), we use CloudFront functions for synchronous path rewriting.

The function now handles two primary rewrite patterns:

  • /track/{trackingToken} → Routes to customer tracking dashboard, requires valid token from jobs.json
  • /book/ → Routes to booking system entry point

Before publishing, we retrieved the current ETag from CloudFront to ensure atomic updates:

Get CF function ETag for update
Publish CF function to LIVE stage
Publish CF function, capture full output

The ETag mechanism prevents race conditions when multiple deployments occur simultaneously, ensuring only one version is published.

Job Creation: Mark's Soderblom Avenue Pickup

Creating a new job in the QuickDumpNow system requires coordinating multiple data stores and generating cryptographically unique identifiers:

  • Job ID: Generated using UUID v4 format, ensuring global uniqueness
  • Tracking Token: Separate from job ID, this is the public-facing identifier that customers receive via SMS/email
  • Job Status: Initialized to ready_for_pickup per customer confirmation that trailer would be available same-day
  • Customer Data: Location (Soderblom Avenue), service type (trailer pickup and dump), price ($600 flat rate)

The job object was constructed in JSON format and uploaded to the S3 bucket serving as the jobs database:

Generate job ID and tracking token for Mark
Build Mark's job JSON
Upload Mark's job to jobs.json

Data structure rationale: Rather than managing a full relational database, QuickDumpNow uses S3 as a JSON document store. This simplifies infrastructure (no database credentials to rotate, automatic versioning, built-in backup), reduces operational overhead, and provides sufficient performance for the dispatch scale (~5-10 jobs per day).

Infrastructure: S3, CloudFront, and Cache Invalidation

The production environment uses a three-tier caching strategy:

  1. S3 Origin: Stores HTML pages (dashboard, track page, booking pages) and job data (jobs.json)
  2. CloudFront Distribution: Caches static assets and HTML pages, applies edge functions for rewriting
  3. Browser Cache: Customers cache dashboard/track pages locally based on Cache-Control headers

After promoting files from staging to production, we invalidated both CloudFront distributions:

Invalidate dashboard CloudFront cache
Invalidate quickdumpnow.com CloudFront cache for track and book paths

Cache invalidation is critical here because:

  • The dashboard displays real-time job status and kanban columns—stale HTML would show outdated status information
  • The track page must immediately recognize Mark's new tracking token
  • Jobs.json updates (status changes) need to be visible within seconds, not minutes

Wildcard vs. path-specific invalidation: We used path-specific invalidation (/track/*, /book/*) rather than invalidating the entire distribution. This preserves cache hits for unrelated assets and reduces CloudFront invalidation API calls (which have quota limits).

Debugging the "Job Not Found" Error

The initial error message ("Job not found, or this tracking link is no longer valid") when visiting a tracking URL indicated several potential issues:

  • The tracking token wasn't being extracted correctly from the URL by the track page JavaScript
  • The token format in Mark's job record didn't match what was expected by the validation logic
  • The track page was pulling stale jobs.json from CloudFront cache
  • The CloudFront rewrite function wasn't correctly routing /track/ requests to the track page origin

Resolution involved:

Read token extraction and fetch logic in track page
Read current prod track page
Hit track API endpoint directly for Mark's token
Verify all replacements landed correctly

By hitting the track API directly and verifying Mark's job existed in jobs.json with the correct token, we confirmed the issue was cache-related. The cache invalidation resolved the error immediately.

Status Flow Architecture

The system manages job lifecycle through a defined state machine. We reviewed and updated status flow definitions:

Read STATUS_FLOW, kanban column logic, and job assignment in dashboard
Read status change and pill logic in dashboard
Patch dashboard with all status flow changes

The status flow defines valid transitions:

  • pending → ready_for_pickup (customer confirms availability)
  • ready_for_pickup → in_progress (crew picks up trailer)
  • in_progress → completed (trailer dumped, job finished)

Each status maps to a visual indicator (status pill with color) in the dashboard kanban board. The statusLabel() and statusColor() functions centralize this mapping, preventing color/label inconsistencies across multiple pages.

Key Decisions

  • S3 + CloudFront over database: Reduced operational complexity while maintaining adequate performance for dispatch scale
  • Edge function rewriting: Kept URL rewrite logic at the CloudFront edge for sub-millisecond latency
  • Separate tracking tokens from job IDs: Prevents URL guessing attacks by using cryptographically random tokens instead of sequential IDs
  • Path-specific cache invalidation: Balanced freshness requirements against CloudFront API quota limits