Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Bulk Artist Event Page Pricing and Asset Updates: Dynamic Price Management Across Multi-Tenant Concert Venues

What Was Done

We executed a comprehensive update to nine artist event pages within the Queen of San Diego concert management system, addressing pricing inconsistencies and missing visual assets. The primary issue: initial placeholder pricing of $275/person was applied uniformly across all artist pages, but market research indicated this was unrealistic for several performers. We needed to implement data-driven, artist-specific pricing while maintaining visual consistency and ensuring the updates propagated correctly across both staging and production environments.

The scope included:

  • Updating pricing for Bonnie Raitt, Mariachi USA, and Weird Al Yankovic (with similar updates pending for six additional artists)
  • Injecting price data into payment button labels ("PAY WITH CARD" and "ZELLE - ZERO FEES" CTAs)
  • Adding artist-specific photography assets to S3 and updating image paths
  • Verifying all changes across staging environment before production promotion
  • Ensuring events.html concert card stubs reflected accurate pricing

Technical Details: Architecture and Implementation

File Structure and Update Strategy

The artist event pages follow a consistent template structure deployed across subdomains:


https://[artistname].queenofsandiego.com/
├── index.html (main page with theme, pricing, hero gallery)
├── css/ (theme-specific styling)
└── assets/ (images, logos)

Each artist page is independently hosted in its own S3 bucket (e.g., bonnieraitt-queenofsandiego.s3.us-west-2.amazonaws.com) and distributed via CloudFront. This multi-bucket approach provides isolation and allows per-artist deployment without impacting other pages.

Pricing Integration Points

Pricing data needed to be updated in three critical locations within each artist's index.html:

  • Hero Section: "From $XX" text visible in the concert card hero gallery
  • Payment Button 1: "PAY WITH CARD - $XX" anchor button
  • Payment Button 2: "ZELLE - ZERO FEES - $XX" anchor button
  • Events Stub: Corresponding concert card in events.html staging environment

The button implementation uses anchor tags with inline pricing text rather than dynamic JavaScript, which meant every price change required direct HTML modification. This decision prioritizes simplicity and cache consistency—once CloudFront serves the updated file, all price data is guaranteed correct without client-side dependencies.

Image Asset Management

We identified that hero-gallery sections referenced image paths that weren't correctly resolving in staging. Typical issue:


<div class="hero-gallery">
  <img src="/assets/bonnie-1.jpg" alt="Bonnie Raitt">
  <img src="/assets/bonnie-2.jpg" alt="Bonnie Raitt">
</div>

These paths needed verification against actual S3 object keys. We discovered that some artist pages had malformed paths (missing subdirectories or incorrect extensions), which would cause 404s when CloudFront attempted to serve them. We corrected paths to match the actual S3 structure:


s3://bonnieraitt-queenofsandiego/images/bonnie-raitt-1.jpg
s3://bonnieraitt-queenofsandiego/images/bonnie-raitt-2.jpg

Infrastructure and Deployment Pipeline

Staging Environment Verification

Before any production changes, we deployed updates to a staging CloudFront distribution pointed at staging S3 buckets. This allowed comprehensive validation:

  • Verified price spans appeared in all concert cards within events.html staging
  • Spot-checked individual artist pages for correct pricing in both hero section and buttons
  • Confirmed hero-gallery images resolved without 404s
  • Validated that price text was visible and properly styled

The command workflow involved sequential checks across multiple artists:


# List staging files in S3 for verification
aws s3 ls s3://bonnieraitt-queenofsandiego-staging/ --recursive

# Verify specific price text appears in staged HTML
grep -n "From \$" bonnieraitt-staging/index.html

# Check hero-gallery image paths
grep -n "hero-gallery\|src=" bonnieraitt-staging/index.html | head -20

AWS Resource Configuration

The infrastructure leverages these AWS services:

  • S3 Buckets: One primary bucket per artist (e.g., bonnieraitt-queenofsandiego.s3.us-west-2.amazonaws.com) plus staging variants
  • CloudFront Distributions: Custom distribution for each artist's domain, with origin pointing to the corresponding S3 bucket. Cache behavior configured for index.html with 24-hour TTL for HTML, longer TTL for static assets
  • Route53: DNS records pointing artist subdomains (bonnieraitt.queenofsandiego.com, mariachiusa.queenofsandiego.com, etc.) to their respective CloudFront distribution domain names
  • S3 Bucket Policies: Each bucket configured to allow CloudFront origin access identity (OAI) to read objects, preventing direct public S3 access

Key Decisions and Rationale

Staging-First Validation

We established a strict staging → production promotion workflow. Given that events.html serves as the master event listing, a broken price display on any single artist page could confuse users across the entire site. By validating all nine pages in staging before promoting, we eliminated the risk of cascading issues.

Static Pricing Over Dynamic

The team chose to hardcode prices directly into HTML buttons rather than implement dynamic pricing via JavaScript. Rationale: reduced complexity, guaranteed consistency with CloudFront caching, and lower latency (no client-side computation). Trade-off: future price changes require HTML updates, but for a concert venue site where pricing changes infrequently, this is acceptable.

Per-Artist S3 Buckets

Rather than consolidating all artist pages into a single bucket with subdirectories, we deployed each artist to its own bucket. This decision enables:

  • Independent scaling and performance optimization
  • Granular access control (only specific teams manage specific artist pages)
  • Simplified disaster recovery (corrupted Bonnie Raitt page doesn't affect Mariachi USA)
  • Easier A/B testing (can run different versions in separate CloudFront distributions)

What's Next

The remaining six artist pages await pricing and asset updates using the same workflow. Once all nine are validated in staging, we'll batch-promote updated CloudFront cache invalidations to ensure users see the latest pricing immediately rather than waiting for the TTL to expire.

Future improvements should consider implementing a lightweight content management layer (e.g., JSON-based price configuration loaded at build time) to reduce manual HTML edits and enable faster bulk updates. A CI/CD pipeline that validates pricing consistency across all pages before deployment would catch pricing mismatches programmatically.