Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Production Deployment of QuickDumpNow Dispatch Rewrite and Customer Job Tracking System

This post documents a critical infrastructure update to the QuickDumpNow platform: deploying a new CloudFront function rewrite layer, promoting the dashboard to production, and establishing the job tracking system with real customer data. The work involved coordinating multiple deployment streams across S3, CloudFront, Lambda, and our job management infrastructure.

What Was Done

We executed a multi-component production deployment for quickdumpnow.com that included:

  • Updated CloudFront function logic to handle both /track/ and /book/ URL rewrites
  • Promoted the QDN dashboard from staging to production
  • Promoted customer tracking pages and booking pages from staging to production
  • Created the first production job record with tracking token for a customer (Mark, Soderblom Ave)
  • Validated the full tracking flow from job creation through customer-facing tracking page

Technical Details: CloudFront Function Rewrite Architecture

The core of this deployment involved updating the CloudFront function responsible for URL rewrites at edge locations. This function intercepts requests to quickdumpnow.com and routes them to the appropriate backend resources.

File Modified: /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js

The function previously handled /track/ path rewrites. We extended it to also manage /book/ rewrites, allowing the CloudFront distribution to serve both customer tracking pages and booking flows through the same edge distribution. This consolidation reduces redirect latency and simplifies routing logic.

The deployment process involved:

  1. Fetching the current CloudFront function ETag to ensure we could perform atomic updates
  2. Publishing the updated function to the LIVE stage of the CloudFront distribution
  3. Verifying the function output to confirm both rewrite rules were active

Infrastructure Changes and Promotion Pipeline

S3 and CloudFront Workflow:

The deployment utilized a staged promotion model:

  • Staging Environment: Dashboard, customer track pages, and booking pages exist in CloudFront staging distributions
  • Production Promotion: Once validated, these resources are promoted to production CloudFront distributions serving quickdumpnow.com

After promotion, we executed targeted CloudFront cache invalidations:

// Invalidate dashboard (all paths)
Invalidate: /dashboard/*

// Invalidate tracking and booking paths
Invalidate: /track/* and /book/*

This pattern ensures end users receive fresh content immediately after deployment, preventing cache-stale issues that could cause the "Job not found" errors we initially encountered.

Job Creation and Tracking Token System

With the infrastructure ready, we created the first production job. The process involved:

  1. Reading Current State: Fetched the existing jobs.json from S3 to determine current job records
  2. Generating Identifiers: Created a unique job ID and tracking token for Mark's Soderblom Ave job
  3. Building Job Record: Constructed Mark's job JSON with:
    • Customer name: Mark
    • Location: Soderblom Ave
    • Service amount: $600
    • Status: Scheduled for afternoon pickup
  4. Persisting to S3: Uploaded the updated jobs.json with Mark's record

The tracking token generated for Mark allows him to access his job status via a unique URL pattern like https://quickdumpnow.com/track/[TOKEN]. This token is stored in the jobs.json file and validated by the customer tracking page.

Validation and Issue Resolution

Initially, accessing Mark's tracking link returned "Job not found, or this tracking link is no longer valid." The issue stemmed from a sequence of events:

  • The CloudFront function rewrite rules weren't yet published to the LIVE stage
  • The dashboard hadn't been promoted to production, so the job management interface wasn't accessible
  • The jobs.json file hadn't been updated with Mark's record

After completing all deployment steps and invalidating the CloudFront cache, the tracking link resolved correctly. This validates that:

  • The /track/ rewrite rule correctly routes requests to the customer tracking page
  • The tracking page successfully queries jobs.json and retrieves Mark's job record
  • The matching logic between tracking token and job record works end-to-end

Key Architectural Decisions

Why CloudFront Functions Instead of Lambda@Edge?

We implemented rewrites using CloudFront Functions rather than Lambda@Edge because this use case involves simple URL pattern matching and rewriting, not complex business logic. CloudFront Functions execute synchronously with minimal latency and no cold starts, making them ideal for routing decisions.

Why Staged Promotion with Cache Invalidation?

Staging environments allow validation before production exposure. The targeted cache invalidations (rather than full distribution invalidation) balance safety with performance—we invalidate only the affected paths, allowing other cached assets to remain warm.

Why Store Jobs in S3 Rather Than a Database?

For this deployment, storing jobs.json in S3 provides simplicity and cost efficiency. The dispatch tool is low-throughput (dozens of jobs daily), making S3's consistency model and per-request pricing more practical than maintaining a relational database. As volume scales, this could be re-evaluated for a DynamoDB or RDS backend.

What's Next

The production deployment is now live. Upcoming work includes:

  • Monitoring CloudFront function performance and error rates for the rewrite rules
  • Testing the booking flow (`/book/` paths) with real customers
  • Implementing automated alerts if tracking link access patterns deviate significantly
  • Planning a migration from S3-based job storage to a queryable database if job volume increases

This deployment establishes the core infrastructure for QuickDumpNow's customer-facing tracking system, enabling customers like Mark to monitor their scheduled pickups in real time.