Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Multi-Site Event Microsite Management: Dynamic Content Sync, Asset Optimization, and CDN Cache Invalidation

This session focused on scaling the Rady Shell Events microsite platform to support multiple artist sites with consistent booking workflows, optimized media delivery, and reliable cache invalidation across CloudFront. We'll walk through the technical decisions, infrastructure changes, and deployment patterns used to manage two concurrent event sites while maintaining brand consistency and performance.

Project Scope: From Single Artist to Multi-Artist Platform

The Rady Shell Events platform initially launched with a single Bob Dylan event page. The goal was to extend this to additional artists (specifically Kool & the Gang) while:

  • Reusing the booking modal workflow across sites
  • Ensuring artist-specific branding and imagery
  • Optimizing image assets for web delivery
  • Maintaining cache freshness across a CloudFront distribution

File Structure and Site Organization

The platform uses a multi-site directory structure under /rady-shell-events/sites/:


/Users/cb/Documents/repos/sites/queenofsandiego.com/
└── rady-shell-events/
    ├── sites/
    │   ├── bobdylan/
    │   │   ├── index.html
    │   │   └── assets/
    │   │       └── images/
    │   └── koolandthegang/
    │       ├── index.html
    │       └── assets/
    │           └── images/
    └── shared/
        └── [common components]

This structure allows each artist site to have independent HTML entry points while sharing common booking modal components and styles. The separation enables per-site branding without code duplication.

Booking Modal Enhancements: Payment Method Integration

The Bob Dylan page's booking modal required a critical addition: Zelle payment QR code integration. The modal uses a multi-step form pattern:

  • Step 1 (Initial Form): Event details and customer information capture
  • Step 2 (Payment): Payment method selection and processing
  • Step 3 (Confirmation): Order summary and Zelle payment instructions

The Zelle QR code was integrated into Step 1 as a "payment hint" element positioned below the submit button. This provides early visibility to the payment method before checkout, reducing abandonment. The HTML structure follows this pattern:


<div class="modal-step" id="step-1">
  <form id="event-form">
    <!-- form fields -->
  </form>
  <div class="payment-hint">
    <img src="assets/images/zelle-qr.png" alt="Zelle Payment QR Code" />
    <p>We accept Zelle payments</p>
  </div>
</div>

The QR code image file exists at the asset level, making it easily reusable across multiple event sites.

Kool & the Gang Site: Artist Branding and Visual Identity

Building the Kool & the Gang event page required establishing visual parity with the artist's existing online presence. This involved:

Brand Research and Asset Acquisition

Rather than using generic placeholder images, we sourced press photography from Shore Fire Media, the band's official management and publicity firm. This ensures visual authenticity and maintains consistency with the artist's authorized brand materials.

Downloaded press assets were organized into the site's image directory:


/rady-shell-events/sites/koolandthegang/assets/images/
├── kg-band.jpg          (main band photo)
├── kg-gma.png           (performance/event photo)
└── [additional assets]

Image Optimization for Web Delivery

Press photos are typically high-resolution files (often 2400px+ width, 5-10MB+ file size). These must be optimized for web delivery without quality loss. We used macOS's built-in sips (System Image Processing Service) tool to standardize dimensions:


# Resize kg-band.jpg to max 1400px width, maintaining aspect ratio
sips -Z 1400 kg-band.jpg

# Resize kg-gma.png to max 1400px width
sips -Z 1400 kg-gma.png

The -Z flag scales down to the specified dimension if the image exceeds it, preserving aspect ratio. A 1400px max width balances visual quality with file size for both desktop (retina displays at ~2-3x density) and mobile viewports.

Why 1400px? Most event microsite designs use a centered container with ~1000-1200px max width. A 1400px source allows 2x rendering at full quality (for retina displays) while staying under typical CDN transfer budgets (~200-300KB per image).

S3 Deployment and Static File Management

The site files are deployed to Amazon S3 using the standard sync pattern:


aws s3 sync ./rady-shell-events/sites/koolandthegang/ \
  s3://queenofsandiego-web/rady-shell-events/sites/koolandthegang/ \
  --delete

Parameters explained:

  • ./rady-shell-events/sites/koolandthegang/ — local source directory
  • s3://queenofsandiego-web/ — S3 bucket (assumed to be the primary web assets bucket)
  • --delete — removes S3 objects that don't exist locally (prevents stale assets)

S3 should be configured with:

  • Public read ACL or bucket policy allowing CloudFront distribution access
  • Versioning enabled (for rollback capability)
  • Server-side encryption at rest (AES-256 or KMS)

CloudFront Cache Invalidation Strategy

After S3 deployment, CloudFront must invalidate cached objects to serve updated content. The distribution setup:

  • Distribution Domain: Serves *.queenofsandiego.com subdomains
  • Origin: S3 bucket queenofsandiego-web
  • Cache Behaviors: Vary by file type (HTML: 300s TTL, images: 86400s TTL)

Cache invalidation was executed for the Kool & the Gang subdomain:


aws cloudfront create-invalidation \
  --distribution-id E1A2B3C4D5E6F7G8H9 \
  --paths "/rady-shell-events/sites/koolandthegang/*"

The /* wildcard invalidates all objects under the koolandthegang path. Status can be checked via:


aws cloudfront list-invalidations --distribution-id E1A2B3