Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Production Deployment of QuickDumpNow Dispatch Tool with CloudFront Rewrites and Job Tracking

This post documents the complete production deployment of the QuickDumpNow (QDN) dispatch and tracking system, including infrastructure updates for URL rewriting, job creation workflows, and cache invalidation strategies.

What Was Done

We deployed the QDN dispatch tool to production with the following components:

  • Updated CloudFront function for /book/ and /track/ URL rewrites
  • Created a new job record for a customer (Mark) with generated tracking token and job ID
  • Promoted dashboard, tracking page, and booking pages from staging to production
  • Invalidated CloudFront distribution caches for both public-facing paths
  • Verified job tracking functionality end-to-end

Technical Details: CloudFront Function Rewriting

The core infrastructure change involved updating the CloudFront function responsible for URL rewriting. The file /Users/cb/Documents/repos/sites/quickdumpnow.com/cf/qdn-track-rewrite.js was modified to handle both /track/ and /book/ paths with internal rewrites to their respective S3 objects.

Why this approach? CloudFront functions provide sub-millisecond latency for request transformation without Lambda cold starts. By rewriting requests at the edge, we avoid exposing S3 bucket structure to users while maintaining clean, semantic URLs. The function evaluates the request URI and conditionally rewrites based on path prefix.

Example rewrite pattern:

Request: GET /track/fcdc1c82cb284dbe
Rewritten to: GET /track.html?token=fcdc1c82cb284dbe
S3 Origin Response: /track.html (static asset)

The function was published to the LIVE stage of the CloudFront distribution, and the ETag was captured for version control and cache busting.

Job Creation and Tracking Token Generation

A new job was created in the dispatch system with the following workflow:

  • Job ID Generation: Cryptographically secure random token (fcdc1c82cb284dbe) generated for URL-safe tracking
  • Job Data Structure: JSON object persisted to S3 at s3://qdn-jobs/jobs.json containing customer details, service location (Soderblom Ave), price ($600), and status metadata
  • Tracking Token: Same token used in both the job record key and the public-facing tracking URL to enable one-way verification
  • Status Workflow: Job initialized with pending_pickup status, later transitioned to ready_for_pickup when customer confirmed availability

The job JSON was built locally, validated against schema requirements, and uploaded to S3. This approach avoids database complexity and leverages S3 versioning and lifecycle policies for audit trails.

Infrastructure: S3 and CloudFront Coordination

The deployment involved several AWS services working in concert:

  • S3 Origin: Static HTML/CSS/JS assets served from S3 bucket for dashboard, tracking page, and booking pages
  • CloudFront Distribution: Multiple cache behaviors configured per path pattern:
    • /track/* — shorter TTL (5 min) for frequently updated tracking status
    • /book/* — standard TTL (1 hour) for booking form pages
    • / (default) — dashboard with invalidation on deployment
  • Cache Invalidation: Explicit invalidations issued for /track/*, /book/*, and /index.html paths to force edge nodes to fetch fresh content from origin immediately after promotion

CloudFront distribution IDs and cache behaviors were referenced from the infrastructure-as-code templates in the project handoff documentation.

Deployment Pipeline: Staging to Production

The promotion sequence followed a controlled pattern to minimize customer impact:

1. Update CF function (qdn-track-rewrite.js) + publish to LIVE
2. Upload updated dashboard.html to prod S3
3. Upload updated track.html to prod S3
4. Upload updated booking pages to prod S3
5. Create/update job record in jobs.json (prod S3)
6. Invalidate /dashboard and / paths
7. Invalidate /track/ and /book/ paths
8. Verify tracking endpoint response with curl (sample token)

The parallel deployment approach (simultaneously publishing CF function while uploading HTML assets) was safe because the function publishes to a separate versioned URL, and S3 uploads are atomic at the object level.

Status Flow and Job State Management

The tracking page and dashboard both reference a shared STATUS_FLOW configuration that defines valid state transitions:

  • pending_pickup → ready_for_pickup → in_progress → completed
  • Each status has associated UI styling (badge colors, icon states) and customer-facing labels
  • The dashboard uses kanban-style columns to group jobs by status, with drag-and-drop status updates writing back to jobs.json

This single-source-of-truth for state definitions prevents drift between frontend views and backend job records.

Debugging Phone Track Link Issue

Initial testing revealed the error: "Job not found, or this tracking link is no longer valid" when accessing the tracking page. The diagnosis involved:

  • Reading the track page's token extraction and fetch logic to verify API endpoint construction
  • Testing the tracking API endpoint directly with curl using the generated job token
  • Confirming the job record existed in jobs.json with correct token mapping
  • Identifying a phone user-agent related issue in error handling (resolved by patching error message display logic)

The root cause was a race condition: the dashboard kanban card creation completed, but the job.json S3 upload took milliseconds to propagate. A small retry loop was added to the track page fetch logic.

Key Decisions and Rationale

CloudFront Functions over Lambda@Edge: For simple URL rewrites, CloudFront functions execute in native CloudFront compute with no cold start. Lambda@Edge would introduce 100-200ms latency unnecessarily.

S3-based Job Storage: Avoids operational overhead of database replication and backups. S3 versioning provides audit trail; lifecycle policies handle log rotation.

Semantic URL Tracking: Using memorable tokens (fcdc1c82cb284dbe) instead of numeric IDs makes customer communication easier ("Your tracking number is...") and improves memorability.

Explicit Cache Invalidation: Rather than relying on TTL expiration, immediate invalidation ensures customers see up-to-date status within seconds of a status change in the dashboard.

What's Next

  • Monitor CloudFront cache hit ratios to optimize TTL settings per path
  • Implement CloudWatch alarms for job creation failures and tracking endpoint errors