Managing 19 WordPress sites means managing 19 IP addresses, 19 DNS records, and 19 potential points of blocking, rate limiting, and geo-restriction. We solved it by routing all traffic through a single Google Cloud Run proxy endpoint that intelligently distributes requests across our estate.
The Problem We Solved
Some of our WordPress sites host sensitive content in regulated verticals. Others are hitting API rate limits from data providers. A few are in restrictive geographic regions. Managing each site’s network layer separately was chaos—different security rules, different rate limit strategies, different failure modes.
We needed one intelligent proxy that could:
– Route traffic to the correct backend based on request properties
– Handle rate limiting intelligently (queue, retry, or serve cached content)
– Manage geographic restrictions transparently
– Pool API quotas across sites
– Provide unified logging and monitoring
Architecture: The Single Endpoint Pattern
We run a Node.js Cloud Run service on a single stable IP. All 19 WordPress installations point their external API calls, webhook receivers, and cross-site requests through this endpoint.
The proxy reads the request headers and query parameters to determine the destination site. Instead of individual sites making direct calls to APIs (which triggers rate limits), requests aggregate at the proxy level. We batch and deduplicate before sending to the actual API.
How It Works in Practice
Example: 5 WordPress sites need weather data for their posts. Instead of 5 separate API calls to the weather service (hitting their rate limit 5 times), the proxy receives 5 requests, deduplicates them to 1 actual API call, and distributes the result to all 5 sites. We’re using 1/5th of our quota.
For blocked IPs or geographic restrictions, the proxy handles the retry logic. If a destination API rejects our request due to IP reputation, the proxy can queue it, try again from a different outbound IP (using Cloud NAT), or serve cached results until the block lifts.
Rate Limiting Strategy
The proxy implements a weighted token bucket algorithm. High-priority sites (revenue-generating clients) get higher quotas. Background batch processes (like SEO crawls) use overflow capacity during off-peak hours. API quota is a shared resource, allocated intelligently instead of wasted on request spikes.
Logging and Observability
Every request hits Cloud Logging. We track:
– Which site made the request
– Which API received it
– Response time and status
– Cache hits vs. misses
– Rate limit decisions
This single source of truth lets us see patterns across all 19 sites instantly. We can spot which integrations are broken, which are inefficient, and which are being overused.
The Implementation Cost
Cloud Run runs on a per-request billing model. Our proxy costs about $50/month because it’s processing relatively lightweight metadata—headers, routing decisions, maybe some transformation. The infrastructure is invisible to the cost model.
Setup time was about 2 weeks to write the routing logic, test failover scenarios, and migrate all 19 sites. The ongoing maintenance is minimal—mostly adding new API routes and tuning rate limit parameters.
Why This Matters
If you’re running more than a handful of WordPress sites that make external API calls, a unified proxy isn’t optional—it’s the difference between efficient resource usage and chaos. It collapses your operational blast radius from 19 separate failure modes down to one well-understood system.
Plus, it’s the foundation for every other optimization we’ve built: cross-site caching, intelligent quota pooling, and unified security policies. One endpoint, one place to think about performance and reliability.
Leave a Reply