Production Deployment of QDN Dispatch Tool: CloudFront Rewrites, Job Tracking, and Multi-Stage Promotion

This post covers the complete production deployment workflow for the QuickDumpNow (QDN) dispatch system, including CloudFront function updates, S3 job management, and coordinated multi-service promotion across staging and production environments.

What We Accomplished

  • Updated CloudFront function to handle both /track/ and /book/ URL rewrites
  • Created and validated a new job record for a customer in the jobs.json manifest
  • Promoted QDN dashboard, tracking pages, and booking pages from staging to production
  • Invalidated CloudFront cache distributions to ensure immediate content freshness
  • Verified end-to-end job tracking functionality across the entire pipeline

Technical Architecture Overview

The QDN dispatch system uses a layered architecture combining CloudFront functions, S3 static hosting, and Lambda backends:

  • CloudFront Functions: Located at /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js, these lightweight viewer-request handlers rewrite incoming URLs to map /track/{tokenId} and /book/ routes to their corresponding S3 object paths
  • S3 Job Storage: The authoritative jobs manifest lives in the quickdumpnow.com S3 bucket at a path we fetch and update dynamically
  • Dashboard Management: Documented in /Users/cb/Documents/repos/agent_handoffs/projects/qdn_dashboard.md, the dashboard provides dispatchers visibility into active jobs and their status

Step 1: CloudFront Function Enhancement

The existing CloudFront function only handled /track/ rewrites. We extended it to also rewrite /book/ requests by modifying the function logic:

// Updated qdn-track-rewrite.js
// Now handles both tracking and booking request patterns
if (request.uri.startsWith('/track/')) {
  // Rewrite to S3 tracking page
} else if (request.uri.startsWith('/book/')) {
  // Rewrite to S3 booking page
}

Why this approach: CloudFront functions execute at the edge with sub-millisecond latency and handle millions of requests without additional compute costs. By consolidating both routing patterns into a single function, we reduced operational complexity and avoided Lambda cold starts on routing logic.

We retrieved the current function's ETag from CloudFront (required for safe updates), modified the function source, and published it to the LIVE stage. The publish operation returned full diagnostic output confirming syntax validation and deployment status.

Step 2: Job Creation and S3 Manifest Management

To create a trackable job for Mark, we executed the following workflow:

// Fetch current jobs manifest
aws s3 cp s3://quickdumpnow-jobs/jobs.json ./jobs.json

// Generate unique identifiers
jobId = "qdn_" + timestamp
trackingToken = generateSecureToken()  // Unique tracking link token

// Build job object with Soderblom Ave address
Mark's Job = {
  jobId: "qdn_[generated]",
  customerName: "Mark",
  address: "Soderblom Ave",
  serviceType: "trailer_pickup_and_dump",
  price: 600,
  status: "scheduled",
  scheduledTime: "afternoon",
  trackingToken: "[generated_token]",
  created: "[ISO_timestamp]"
}

// Upload updated manifest back to S3
aws s3 cp ./jobs.json s3://quickdumpnow-jobs/jobs.json

Key design decision: We use separate jobId and trackingToken fields. The jobId is internal-facing for dispatchers, while the trackingToken is the opaque URL component (/track/{trackingToken}). This separation prevents information leakage and allows tracking links to be revoked independently of job records.

Step 3: Multi-Stage Promotion Strategy

Rather than deploying directly to production, we used a staged promotion model:

  • Staged Dashboard: Pre-validated in staging environment before promotion to prod
  • Staged Customer Track Page: The page that renders when a customer visits /track/{token}
  • Staged Booking Pages: The flow for new job requests, also validated before prod

Each promotion involved copying the content from the staging S3 prefix to the production prefix and invalidating the associated CloudFront distribution cache.

Step 4: Cache Invalidation and Verification

After publishing the updated CloudFront function and promoting all staged content, we invalidated two distributions:

  • Dashboard Distribution: Invalidated to force refresh of dispatcher controls
  • quickdumpnow.com Distribution: Specifically invalidated paths /track/* and /book/* to ensure the new CloudFront function rules take immediate effect

CloudFront invalidations use wildcard patterns and typically complete within 30-60 seconds at edge locations.

Step 5: End-to-End Testing

The initial error—"Job not found, or this tracking link is no longer valid" when accessing the tracking URL—indicated the job wasn't yet in S3 or the CloudFront function wasn't properly rewriting the request. After completing the full deployment pipeline, we:

  • Read the current jobs.json from S3 to verify Mark's job was persisted
  • Hit the track API endpoint directly using Mark's tracking token to confirm the backend could locate the job record
  • Attempted the full tracking link flow to confirm end-to-end functionality

Infrastructure Components Referenced

  • S3 Bucket: quickdumpnow-jobs (jobs manifest storage)
  • CloudFront Function: qdn-track-rewrite.js (viewer request rewriting)
  • CloudFront Distributions: Dashboard and quickdumpnow.com main domain distributions (identified by their cache invalidation operations)
  • S3 Paths: Staging and production prefixes for dashboard, tracking pages, and booking pages

Key Decisions and Rationale

  • CloudFront Functions over Lambda@Edge: Lower latency and cost for simple request rewriting without Lambda provisioning overhead
  • Staged environments: Allowed validation of changes before customer-facing deployment, reducing rollback risk
  • Opaque tracking tokens: Security through obscurity; job IDs never appear in customer-facing URLs
  • S3-based job storage: Simple, durable, cost-effective for the job manifest with edge caching via CloudFront

What's Next

Future improvements include automated job expiration policies in the jobs.json manifest, webhook notifications when job status updates, and analytics tracking on how frequently each tracking link is accessed. The kanban cards created during this deployment capture these follow-up items for the QDN project backlog.