Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Production Deployment of QuickDumpNow Dispatch System: Multi-Stage CloudFront Rewrite Architecture

Overview

This deployment unified the QuickDumpNow dispatch tooling across multiple CloudFront distributions with a sophisticated URL rewriting strategy. The core challenge was managing request routing for both customer tracking pages and booking interfaces while maintaining backward compatibility with existing tracking links—all without modifying Route53 DNS configuration.

What Was Done

  • Updated CloudFront Functions to handle dynamic path rewrites for /track/ and /book/ endpoints
  • Promoted staging versions of dashboard, tracking page, and booking pages to production
  • Created and published a new job record for a customer pickup on Soderblom Avenue
  • Invalidated CloudFront cache distributions to ensure immediate content propagation
  • Verified end-to-end tracking flow with real job data

Technical Details: CloudFront Function Rewriting Strategy

The deployment centered on modifying /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js, a CloudFront Functions script that intercepts HTTP requests at edge locations.

Why CloudFront Functions instead of Lambda@Edge? CloudFront Functions offer sub-millisecond execution latency and are ideal for simple request/response transformations. Lambda@Edge would be overkill for URL rewriting and would introduce unnecessary coldstart latency.

The function performs request-time path rewriting:

// Example rewrite logic structure
if (request.uri.startsWith('/track/')) {
  // Extract tracking token and rewrite to origin path
  request.uri = '/track.html';
  request.headers['x-tracking-token'] = extractToken(originalUri);
}

if (request.uri.startsWith('/book/')) {
  // Rewrite booking requests to booking interface
  request.uri = '/booking.html';
}

This approach keeps origin path structures unchanged while providing semantic, customer-facing URLs. The tracking token is passed via a custom header to the origin, where JavaScript extracts it from headers rather than URL parsing.

Job Creation and S3 Integration

A new job record was generated for the customer "Mark" with the following workflow:

  1. Token Generation: Created a cryptographically unique tracking token and corresponding job ID
  2. Job JSON Structure: Built a job document containing customer name, pickup address (Soderblom Ave), service type, pricing ($600 all-in), and status ("ready_for_pickup")
  3. S3 Storage: Uploaded the job record to the QDN S3 bucket in jobs.json, which serves as the source-of-truth job registry
  4. Status Tracking: Set initial job status to align with Mark's afternoon pickup availability

The jobs.json structure uses a flat document model with job IDs as keys, allowing O(1) lookup via the tracking token and enabling efficient CloudFront caching of the entire manifest.

Deployment Pipeline and Staging Promotion

The dispatch system uses a multi-stage deployment architecture:

Staging Environment → Production Environment
/track-staging/     → /track/
/dashboard-staging/ → /dashboard/
/book-staging/      → /book/

The promotion workflow fetched current versions from staging CloudFront distributions and pushed them to production distributions. This staging/prod separation allows testing of URI rewriting rules and status flow changes before affecting customers.

Key decision: Why not use S3 versioning alone? CloudFront distributions maintain their own caching and invalidation semantics. By maintaining separate staging and production distributions, we gain:

  • Independent cache invalidation strategies (staging can have aggressive TTLs; production uses conservative TTLs)
  • Ability to test CloudFront Functions behavior (caching headers, rewrites) in staging before production traffic
  • Clean rollback capability: promote previous production version back to active if needed

Cache Invalidation Strategy

After promoting staged assets to production, the deployment triggered CloudFront cache invalidations on two distributions:

// Invalidation paths for QuickDumpNow production distribution
/dashboard/*
/track/*
/book/*

// Invalidation paths for quickdumpnow.com root distribution  
/track/*
/book/*

CloudFront invalidations were issued with wildcard patterns to ensure that:

  • HTML document caches (zero or short TTL) refresh immediately
  • JavaScript and CSS assets referenced by new HTML versions are re-fetched
  • No stale asset-to-document mismatches occur during propagation

The invalidation captures full command output to confirm success across all edge locations (typically propagates within 30-60 seconds to 95% of global edges).

Tracking Link Validation

After deployment, verification confirmed that the tracking endpoint resolved correctly. The user initially encountered a "Job not found" error on mobile, which was resolved by:

  1. Confirming the job record successfully uploaded to S3 jobs.json
  2. Verifying the track page correctly extracts the token from the CloudFront rewritten request
  3. Confirming the track page JavaScript fetches jobs.json from the origin and performs token-to-job lookup
  4. Invalidating CloudFront cache to ensure the mobile client received the latest track page code

The tracking flow now works: https://quickdumpnow.com/track/[TOKEN] → CloudFront rewrites to /track.html → Browser executes track page JS → JS extracts token from custom header → JS fetches jobs.json → JS displays job details for Mark's Soderblom Ave pickup.

Key Infrastructure Components

  • S3 Bucket: Stores jobs.json (source-of-truth registry), track.html, dashboard.html, and related assets
  • CloudFront Distributions: Primary distribution for quickdumpnow.com with staging and production aliases
  • CloudFront Functions: qdn-track-rewrite.js for request-time path rewrites
  • Origin: S3 configured with proper Cache-Control headers and public-read ACLs

What's Next

With the production deployment complete and Mark's job live on the tracking system, the next phase involves:

  • Monitor CloudWatch metrics for track page load times and jobs.json fetch latency to validate CloudFront performance
  • If additional job status flows are needed (e.g., "in_progress", "completed"), update the STATUS_FLOW constant in dashboard.html and re-promote
  • Consider implementing job listing/search if the dispatcher wants to view all active jobs from the dashboard

The architecture is now ready to scale: new jobs can be created by uploading records to jobs.json, and customers can track them via semantic URLs backed by CloudFront's global edge network.