Architecture Overview

Scottsdale Mint is a serverless WordPress e-commerce platform built on AWS infrastructure, optimized for high-concurrency precious metals transactions with real-time pricing.

---

System Architecture Diagram

┌────────────────────────────────────────────────────────────────────┐
│                        EXTERNAL SYSTEMS                            │
│  NFusion Pricing API ──→ Laravel Middleware ──→ WP REST API        │
│  (spot prices)            (price transform)    (/suma/v1/update-prices) │
└────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────┐
│                     AWS CloudFront CDN                             │
│    - Static asset caching          - Image processing             │
│    - WooCommerce session cookies   - CloudFront IP header          │
│    - Bypass: /cart, /checkout, /my-account, /uploads/elementor    │
└────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────┐
│              AWS Lambda (Ymir — WordPress Runtime)                 │
│                                                                    │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │                WordPress (Bedrock)                           │  │
│  │  ┌─────────────┐  ┌──────────────┐  ┌──────────────────┐   │  │
│  │  │   WP Core   │  │ WooCommerce  │  │  Elementor Pro   │   │  │
│  │  │   6.9.1     │  │   10.5.1     │  │    3.35.3        │   │  │
│  │  └─────────────┘  └──────────────┘  └──────────────────┘   │  │
│  │                                                              │  │
│  │  ┌──────────────────────────────────────────────────────┐   │  │
│  │  │          suma-elementor Theme (v2.3.0)               │   │  │
│  │  │  Pricing • WooCommerce • REST API • Klaviyo • Yotpo  │   │  │
│  │  └──────────────────────────────────────────────────────┘   │  │
│  │                                                              │  │
│  │  Custom Plugins: ACH Gateway • WooEmails • OrderTracking    │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                                                                    │
│  Memory: 4096MB (prod)  │  Timeout: 120s  │  Concurrency: 800    │
└────────────────────────────────────────────────────────────────────┘
         │                    │                      │
         ▼                    ▼                      ▼
┌──────────────┐   ┌──────────────────┐   ┌──────────────────────┐
│ Amazon S3    │   │  Amazon Aurora   │   │  Valkey / Redis      │
│              │   │  MySQL           │   │  (Object Cache Pro)  │
│ - Uploads    │   │  - WP database   │   │  - Object cache      │
│ - KYC docs   │   │  - Read replica  │   │  - Session data      │
│ - Backups    │   │    endpoint      │   │  - Transients        │
└──────────────┘   └──────────────────┘   └──────────────────────┘

---

Key Architectural Decisions

Serverless Lambda (Ymir)

WordPress runs in AWS Lambda functions via Ymir. This means:

• No persistent processes — each request spawns a fresh Lambda invocation.
• External cron — DISABLE_WP_CRON=1 is always set; scheduled tasks run via Ymir's built-in cron runner (cron: 1 in ymir.yml).
• Ephemeral filesystem — no persistent file writes. Uploads go to S3. Logs go to PHP stderr (CloudWatch).
• Cold starts — Ymir's "warmup" feature pre-warms the Lambda pool on deploy (100 requests in production).

Bedrock Framework

Roots.io Bedrock provides:

• All dependencies via Composer — WordPress core, all plugins, and the theme are in composer.json.
• Environment-based configuration — secrets in .env, logic in config/environments/*.php.
• Hardened paths — WordPress core is at /web/wp/, content at /web/app/ (not publicly writable).
• No direct file editing in production — DISALLOW_FILE_EDIT=true, DISALLOW_FILE_MODS=true.

Split Aurora Endpoints

The database uses Amazon Aurora MySQL with separate read and write endpoints:

• DB_WRITER_HOST — All write operations (INSERT, UPDATE, DELETE)
• DB_READER_HOST — All read operations (SELECT), cached queries

Multi-Layer Cache

See Caching Architecture for full detail.

1. CloudFront CDN — Edge caching for static assets, product pages
2. Valkey/Redis — Object cache (transients, query cache, session data)
3. Browser cache — Static assets, product images

Real-Time Pricing Architecture

Precious metals prices update every minute:

NFusion API
    │
    ▼
Laravel Middleware (external — not in this repo)
    │  (transforms spot prices, calculates premiums, applies tiers)
    ▼
POST /wp-json/suma/v1/product/update-prices
    │  (REST endpoint in suma-elementor/inc/endpoints/class-pricing.php)
    ▼
WooCommerce product prices updated in Aurora
    │
    ▼
Redis object cache invalidated for updated products
    │
    ▼
CloudFront cache invalidated for updated product pages

This endpoint is performance-critical. Do not add blocking operations or slow DB queries to the price update path.

---

Request Flow

Standard Page Load (Cached)

Browser → CloudFront (cache hit) → Response

Standard Page Load (Cache Miss)

Browser → CloudFront → Lambda (WordPress) → Aurora Read Replica → Redis
         → Response → CloudFront caches response

Checkout and Cart

These paths are excluded from CloudFront caching (/cart, /checkout, /my-account):

Browser → CloudFront (bypass) → Lambda (WordPress) → Aurora Write + Read → Redis

Payment Processing (e.g., ACH)

Browser → checkout page → ACH Gateway →
    Plaid API (bank account auth) →
    iTransact API (ACH submission) →
    Kount (fraud pre-auth) →
    Kount ENS callback to /wp-json/kount/v1/ens →
    WC order status updated → Customer notified via Mailgun

---

Concurrency and Scaling

Environment	Lambda Concurrency	Memory	Warmup
Production	800	4096 MB	100 requests
Staging	100	2048 MB	40 requests
Development	80	2048 MB	20 requests

Lambda scales horizontally — at 800 concurrency, up to 800 simultaneous requests can be handled. Aurora and Redis are the scalability bottlenecks; both are managed by AWS.

---

Security Boundaries

Layer	Mechanism
HTTPS everywhere	CloudFront HTTPS only; FORCE_SSL_ADMIN=true
Admin access	2FA mandatory (WP 2FA Premium + Twilio)
Payment fraud	Kount Pre-Auth on all payment methods
File modification	DISALLOW_FILE_EDIT=true, DISALLOW_FILE_MODS=true
SQL injection	All queries via $wpdb->prepare() or WP Query API
XSS	All output escaped via WP functions
CSRF	WP nonces on all AJAX/form submissions
IP spoofing	wp-config.php handles CloudFront + Cloudflare headers correctly
HSTS	headers-security-advanced-hsts-wp plugin
Data encryption	SENSITIVE_DATA_KEY for sensitive data at rest