Nathan Wrigley speaks with Saumya Majumder, lead software engineer at BigScoots, about the recent Cloudflare outage, how such incidents affect websites, and the performance and reliability approaches BigScoots uses for WordPress.
Background
Saumya focuses on high-performance WordPress engineering and Cloudflare-centric architectures. Over the years he has built caching systems, migration tools, worker automations, and edge solutions. He supports enterprise customers, runs internal WordPress projects, and helps create developer-friendly, scalable hosting.
What caused the Cloudflare outage
Saumya explains that modern internet platforms like Cloudflare are far more than simple CDNs; they are complex, interdependent systems. Low-probability edge cases—an unexpected configuration, a change in file size, or an uncommon request pattern—can cascade through layers and trigger wide failures. Fixing the root cause and propagating the repair across hundreds of points of presence and internal networks takes time, and mitigation itself can be complicated by traffic surges and propagation delays.
Outages are inevitable in large distributed systems; no provider is immune. Enterprises expect rapid remediation and rely on SLAs, but hidden dependencies and rare edge cases still cause incidents. Saumya praises Cloudflare’s transparency, noting the value of detailed postmortems that describe what happened, how it was fixed, and what will prevent recurrence.
BigScoots’ mitigation strategy
When public-facing Cloudflare services were impacted (for example, captcha and similar features), BigScoots used its own tooling and APIs to reduce customer pain. For sites using Cloudflare as a proxy, BigScoots automated a temporary unproxy via the Cloudflare API so traffic was routed directly to BigScoots’ origin servers. That approach restored logins and access for many WordPress sites that otherwise depended on Cloudflare features.
Saumya stresses the importance of architecture: if your application is hosted entirely on Cloudflare Workers or the edge platform, an API-based unproxy won’t help—those workloads remain affected by Cloudflare outages. Whether Cloudflare is used as a proxy in front of an origin or as the primary host changes what recovery options are available.
Why organizations use Cloudflare anyway
Despite the risks, Cloudflare’s scale, global backbone, security features, serverless platform, and developer tooling make it attractive. For many sites the performance and features are unique. Saumya also notes Cloudflare’s track record of learning from incidents and removing problematic external dependencies, which builds trust over time.
CDN-level page caching: BigScoots’ approach
Saumya describes the evolution from server-side caches and static-file CDNs to the idea of serving full HTML pages from a CDN. Caching full HTML at PoPs means users don’t need to fetch HTML from an origin across long distances. Saumya and a colleague built early CDN-level page caching (later acquired) to serve page HTML globally.
On Cloudflare Enterprise, BigScoots enables global page caching with high hit ratios, tiered caching, and regional tiering. Tiered caching lets local PoPs consult higher-tier PoPs within Cloudflare’s private backbone before falling back to the origin, reducing origin requests and keeping responses fast.
Private interconnects for better performance
BigScoots operates its own data centers and maintains private physical connections to Cloudflare. Instead of Cloudflare fetching content over the public internet, these private links allow traffic to travel over a dedicated, high-bandwidth path. That lowers latency, reduces congestion, and speeds cache fills and origin responses.
This direct connectivity is practical because BigScoots owns infrastructure. Hosts that lease infrastructure from hyperscalers may not be able to create equivalent private links to Cloudflare.
BigScoots Cache plugin and portal controls
BigScoots developed BigScoots Cache to integrate WordPress with Cloudflare Enterprise and provide granular control:
– CDN-level HTML caching so pages are cached at PoPs worldwide.
– Intelligent purging that clears related pages (taxonomies, archives, author pages) when content changes, improving cache consistency.
– Hooks and extensibility for developers to customise TTLs, purge rules, or target non-standard pages.
– A REST API for programmatic purges, useful for headless sites or external systems.
– Portal controls exposing many Cloudflare Enterprise features (geoblocking, image optimisation, bot protections, WAF, login hardening) as simple toggles for non-experts while keeping advanced options available.
Target customers and managed services
BigScoots serves small sites, agencies, and enterprise customers. For larger clients they provide systematic onboarding, zero-downtime migrations, performance tuning, and managed support. Customers who prefer not to adjust advanced settings can rely on BigScoots’ support team to configure and maintain caching and security rules.
Engineering philosophy
Saumya treats caching and large-scale system design as continuous work. Edge cases and new requirements always arise, so R&D remains ongoing—recent efforts include edge and login-user caching protections and other longer-term projects.
Key takeaways
– Outages happen even at top providers; response, transparency, and learning are what matter.
– Architecture determines mitigation options: using Cloudflare as a proxy allows origin-directed failover; fully edge-hosted workloads have different constraints.
– Combining Cloudflare Enterprise, private interconnects, and a host-managed caching layer can yield meaningful performance and reliability gains for WordPress sites.
– Many advanced features are exposed through a user-friendly UI or can be managed by BigScoots’ team; developer hooks and APIs are available for deep integrations.
For the full conversation and links, search for the episode at wptavern.com/podcast.