Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Multi-Stage Deployment Pipeline: Shipping the QuickDumpNow Dispatch Tool to Production

This post covers a complete production deployment of the QuickDumpNow (QDN) dispatch and tracking system, including CloudFront function updates, S3 promotion workflows, and real-time job creation. We'll walk through the architectural decisions, deployment sequencing, and infrastructure changes that enabled shipping new functionality while maintaining zero-downtime updates.

What We Deployed

The QuickDumpNow dispatch tool needed three major updates pushed to production:

  • CloudFront URL rewrite function enhancements (handling both /track/ and /book/ paths)
  • Updated dashboard UI with refined job status flows and visual indicators
  • Enhanced customer tracking page with improved error handling and status displays
  • Backend Lambda function modifications for improved job processing

Additionally, we needed to create an active job record for a customer (Mark) with a specific pickup location and price point ($600 all-in), generating a tracking token so he could monitor his job status in real-time.

Infrastructure Architecture

S3 and CloudFront Distribution

The QuickDumpNow application is hosted on S3 with CloudFront as the CDN layer. The relevant buckets and distributions:

  • Primary bucket: quickdumpnow.com (stores dashboard, tracking pages, and static assets)
  • CloudFront Distribution: Serves requests for quickdumpnow.com with caching policies optimized for dynamic content
  • S3 objects structure:
    • index.html — Dashboard application
    • track/index.html — Customer tracking page (rewritten by CF function)
    • book/index.html — Booking page (newly rewritten)
    • jobs.json — Job state database (dynamically updated)

CloudFront Function for URL Rewriting

CloudFront Functions provide sub-millisecond request/response manipulation at edge locations. Our function, stored at /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js, handles two critical rewrite rules:

// Track endpoint: /track/{token} → /track/index.html
// Book endpoint: /book/ → /book/index.html
// Both preserve query parameters for frontend routing

Why CloudFront Functions instead of Lambda@Edge? CF Functions execute at every edge location with sub-millisecond latency, no cold starts, and lower cost. They're ideal for deterministic URL rewrites. Lambda@Edge would add 50-200ms per request due to regional execution and initialization overhead.

After modifying the function source, we published it to the LIVE stage using the CloudFront API:

aws cloudfront publish-function \
  --name qdn-track-rewrite \
  --if-match {ETAG} \
  --function-code fileb://cf/qdn-track-rewrite.js

The ETag (Entity Tag) is critical — CloudFront uses it for optimistic concurrency control. Publishing without the current ETag fails, preventing race conditions in multi-engineer environments.

Lambda Backend for Job Management

The backend Lambda function at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py handles:

  • Job creation with unique IDs and tracking tokens
  • Status transitions (from pending to ready_for_pickup to completed)
  • Customer data association (name, phone, location)
  • Persistence to S3 jobs.json for frontend consumption

The Lambda function generates a secure tracking token on job creation, allowing customers to access their job via a unique URL without authentication:

POST /api/jobs
{
  "customer_name": "Mark",
  "location": "Soderblom Ave",
  "price": 600,
  "status": "pending"
}

# Returns:
{
  "job_id": "jXkL9m2pQ",
  "tracking_token": "fcdc1c82cb284dbe",
  "tracking_url": "https://quickdumpnow.com/track/fcdc1c82cb284dbe"
}

Deployment Workflow: Staged Promotion Strategy

We used a three-tier promotion strategy to minimize risk:

  • Stage 1 (Development): S3 staging bucket with staging CloudFront distribution
  • Stage 2 (Pre-Production): Validation that files render correctly and CF function rewrites work
  • Stage 3 (Production): Live S3 bucket and production CloudFront distribution

Deployment sequence for zero-downtime:

1. Fetch current jobs.json from production S3
2. Update CloudFront function code and publish to LIVE
3. Upload dashboard to staging S3, validate in browser
4. Upload tracking page to staging S3, test with sample token
5. Upload booking pages to staging S3, validate form submission
6. Promote files from staging → production S3
7. Invalidate CloudFront cache for affected paths
8. Create job record for Mark in jobs.json
9. Push updated jobs.json to production S3
10. Final CloudFront invalidation

Why staged promotion? This pattern allows engineers to verify rendering, API calls, and redirect logic before affecting live customers. If anything breaks, production remains on the previous version.

CloudFront Cache Invalidation

After promoting files to production, we invalidated specific cache patterns:

aws cloudfront create-invalidation \
  --distribution-id {DIST_ID} \
  --paths "/*" "/track/*" "/book/*" "/jobs.json"

Invalidating /* forces all edge locations to refetch from origin. More surgical patterns like /track/* minimize blast radius but ensure tracking pages reflect updates immediately. The /jobs.json path is critical — customers need to see Mark's job appear in real-time.

Job Creation and Token Generation

Once infrastructure was live, we created Mark's job with specific parameters:

# Generate unique job ID and tracking token
job_id = generate_uuid_short()  # "jXkL9m2pQ"
tracking_token = generate_secure_token()  # "fcdc1c82cb284dbe"

# Build job object
mark_job = {
  "id": job_id,
  "customer": "Mark",
  "location": "Soderblom Ave",
  "price": 600,
  "token": tracking_token,
  "status": "pending",
  "created_at": ISO8601_timestamp(),
  "updated_at": ISO8601_timestamp()
}

The job was appended to jobs.json in the S3 bucket and pushed to production. When Mark visits https://quickdumpnow.com/track/fcdc1c82cb284dbe: