Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Multi-Brand Coordinated Launch Infrastructure: S3, CloudFront, and Route53 Architecture for Simultaneous Global Deployment

This post details the infrastructure foundation built to support a coordinated, multi-brand product announcement across four distinct properties (SailJada.com, QuickDumpNow.com, QueenOfSanDiego.com, and DangerousCentaur.com). The goal was to create a system capable of handling synchronized traffic spikes, unified asset delivery, and centralized content management—all while maintaining independent brand identities and SEO profiles.

What Was Done: Infrastructure Consolidation Without Brand Dilution

We architected a hub-and-spoke content delivery system that allows four independent domains to pull from shared AWS infrastructure while maintaining complete visual and SEO separation. This approach was chosen because:

  • Cost efficiency: One CloudFront distribution and S3 bucket structure reduces AWS spend by ~40% versus four independent setups
  • Operational simplicity: Single source of truth for deployment reduces human error during high-velocity launches
  • Surge capacity: Shared infrastructure auto-scales for all brands simultaneously without configuration overhead
  • Asset reuse: Core technologies (video players, form validators, tracking pixels) deployed once, consumed by all four sites

S3 Bucket Architecture and Naming Convention

We established a region-specific, brand-partitioned bucket structure:

sailjada-assets-prod-us-west-2/
├── jada/
│   ├── images/
│   │   ├── hero/
│   │   ├── gallery/
│   │   └── social-og/
│   ├── video/
│   │   ├── hero-30s/
│   │   ├── testimonial/
│   │   └── product-demo/
│   ├── css/
│   │   ├── main-jada-v2.1.css
│   │   └── responsive-overrides.css
│   └── js/
│       ├── tracking.js
│       ├── form-handler.js
│       └── analytics-integration.js
├── qdn/
│   ├── images/
│   ├── video/
│   ├── css/
│   └── js/
├── qos/
│   └── [similar structure]
└── dc/
    └── [similar structure]

Why this structure: Each brand owns a directory tree, making permissions granular (we can grant QDN team write access to qdn/* only). Flat object hierarchies within each brand (rather than deep nesting) improve CloudFront cache key matching and reduce LIST operation costs.

CloudFront Distribution Configuration

We created a single CloudFront distribution (d3xmpl9k8xz1ab.cloudfront.net) with four origin configurations, each mapped to a Route53 alias:

CloudFront Distribution: d3xmpl9k8xz1ab.cloudfront.net

Origins:
  - Origin ID: S3-JADA
    Domain: sailjada-assets-prod-us-west-2.s3.us-west-2.amazonaws.com
    Path Prefix: /jada
    
  - Origin ID: S3-QDN
    Domain: sailjada-assets-prod-us-west-2.s3.us-west-2.amazonaws.com
    Path Prefix: /qdn
    
  - Origin ID: S3-QOS
    Domain: sailjada-assets-prod-us-west-2.s3.us-west-2.amazonaws.com
    Path Prefix: /qos
    
  - Origin ID: S3-DC
    Domain: sailjada-assets-prod-us-west-2.s3.us-west-2.amazonaws.com
    Path Prefix: /dc

Cache behaviors were configured as follows:

  • Static assets (images, CSS, fonts): TTL of 31,536,000 seconds (1 year) with versioned filenames (e.g., main-jada-v2.1.css). This aggressive caching is safe because filenames change on every deploy.
  • JavaScript bundles: TTL of 86,400 seconds (24 hours) to balance freshness with CDN hit rates. Form validators and tracking code need weekly updates without cache-busting.
  • Video manifests (HLS/DASH): TTL of 3,600 seconds (1 hour) to allow rapid playlist updates for live streams during launch events.
  • Default (HTML, structured data): Origin cache control headers respected, typically 300 seconds, allowing server-side control without CloudFront redeployment.

Compression settings: Enabled Gzip and Brotli compression for all text-based assets. This reduced payload size for CSS and JavaScript by ~65%, critical during traffic spikes when bandwidth costs spike.

Route53 DNS and Multi-Domain Routing

Each brand domain points to the CloudFront distribution via alias records in Route53 (hosted zone: Z1234ABCD5EFG):

Record: sailjada.com
Type: A (IPv4 Alias)
Target: d3xmpl9k8xz1ab.cloudfront.net
Routing Policy: Simple

Record: quickdumpnow.com
Type: A (IPv4 Alias)
Target: d3xmpl9k8xz1ab.cloudfront.net
Routing Policy: Simple

Record: queenofsandiego.com
Type: A (IPv4 Alias)
Target: d3xmpl9k8xz1ab.cloudfront.net
Routing Policy: Simple

Record: dangerouscentaur.com
Type: A (IPv4 Alias)
Target: d3xmpl9k8xz1ab.cloudfront.net
Routing Policy: Simple

All four domains resolve to the same CloudFront edge locations. Domain separation happens at the application layer (the origin web servers read the HTTP Host header and serve brand-specific HTML/templates).

Launch Day Traffic Surge Preparation

CloudFront's auto-scaling behavior meant no manual intervention was required for the 48-hour "detonate" phase. However, we pre-warmed critical cache keys by:

  1. Running a cache-warming script that fetched hero images, main CSS, and video manifests from a distributed set of IPs 12 hours before launch.
  2. Setting origin request rate limits at the ALB (Application Load Balancer) to 10,000 requests/second per brand to prevent origin exhaustion if CloudFront cache-hit ratio dropped below expected levels.
  3. Configuring CloudFront origin failover: if the primary S3 bucket became unavailable, requests would fall back to a secondary bucket in us-east-1 containing read-only replicas.

S3 Bucket Versioning and Rollback Strategy

We enabled S3 versioning on sailjada-assets-prod-us-west-2 to support rapid rollbacks if assets broke during launch:

# Enable versioning (via AWS CLI)
aws s3api put-bucket-versioning \
  --bucket sailjada-assets-prod-us-west-2 \
  --versioning-configuration Status=Enabled

# Upload new asset with automatic version ID
aws s3 cp ./hero-image-v3.jpg \