PADI Axelerant
padi.com Enterprise Architecture
v1.1 · 6 November 2026
Work in progress · Version 1.1, last updated 6 November 2026
Quality attributes

Resilience and recovery

The website keeps serving from cache when the CMS fails. These are the failure modes, the degradation path, rollback and the recovery posture.

Failure modes

Component Failure Detection What visitors see Mitigation Recovery owner
Drupal CMS Slow or erroring Frontend error spans Cached pages keep serving (up to 24 h, plus stale copies for a day on 500–504). Uncached pages use each server's last good copy for up to 6 h. After that, an error page. Circuit breaker, load shedding, last good copies Axelerant, Acquia for the platform
Drupal CMS Returns empty content with a 200 Empty-content check Page served as degraded with a 30 s lifetime Empty responses treated as failures Axelerant
Cloudflare purge Rate limited or failing Purge monitors Changes appear late, up to the page lifetime Up to 6 attempts with backoff, second purge, dead-letter retry Axelerant
Next.js servers Overloaded Acquia 5xx, runtime metrics 503 for 30 to 90 s on uncached pages; cached pages unaffected Long edge lifetime, load shedding, autoscaling Acquia and Axelerant
Acquia origin Unreachable (Cloudflare 52x) Cloudflare origin metrics 522 error after about 20 s Acquia platform redundancy Acquia
Edge Workers Exception Frontend synthetic checks through Cloudflare Routing or localisation fails on web hosts Workers fail open Axelerant
Cloudflare cache rule Personal page cached by mistake Privacy test (no cookies on cached responses) Privacy exposure Rules exclude cookies and personal paths; disable through Terraform Axelerant
PADI platform APIs Slow or unavailable Client spans MyPADI slower or modules missing; public pages unaffected Request caps, per-server caches, closed-by-default menu items PADI
Finder APIs Host, OpenSearch or Aurora failure Latency and 5xx monitors, synthetic checks Finder and search sections show an error Autoscaling replaces hosts; previous index generation Axelerant
Finder data feed Stream lag, bad record, drift Stream age, lag and drift monitors Shop and course data goes stale; searches still work Replay-safe ingest, rebuild, DMS reload Axelerant and PADI Travel
Finder NAT gateway Zone outage AWS No visible effect; outbound calls and new hosts wait Running hosts keep serving Axelerant
Datadog intake Slow or down Export failure metric None 1 s timeout, no retries Axelerant

Degradation path

A fresh edge copy is served first, then a stale one (up to 1 day) when the origin returns 500 to 504. A saturated server answers 503 with a 5 s retry. When Drupal times out or the circuit breaker is open, the frontend serves its last good copy, cached for 30 s only. The full sequence is in Page request.

Rollback

System Rollback, fastest first
Frontend Change edge-cache switches; disable a Cloudflare rule; switch the Acquia environment to the previous tag
Drupal Switch to the previous tag; restore the pre-deploy database backup (staging and production); full cache purge
Cloudflare Revert the Terraform change; Workers fail open
Finder Point the search aliases at the previous index generation; redeploy the previous release
www.padi.com cutover Switch the www origin back inside Cloudflare (no DNS change)

Backup and disaster recovery

System Backup and recovery Redundancy
Drupal Daily Acquia backup of every CMS database (about 09:50 UTC in production), keeping the last 3 to 5; a backup before each staging and production deploy Acquia-managed
Next.js Immutable release tags; rebuild from Git Acquia autoscaling
Cloudflare configuration Terraform with remote state Cloudflare global network
FinderDB Aurora point-in-time recovery, 14 days Writer today; reader added before launch
OpenSearch Rebuildable from FinderDB; previous generation kept 1 node today; 3 nodes with a replica before launch
Finder data feed DMS can reload from PADI Travel PADI Travel-managed stream
PADI Travel database AWS point-in-time recovery, 7 days PADI-managed