Proxying with Tencent EdgeOne Makers

When building web applications that rely on localized servers or third-party APIs, developers face recurring infrastructure headaches: upstream rate limits, unexpected downtime, high geographic latency for international users, and ballooning cloud compute costs.

While building rafifmsn/exchange, a lightweight currency converter and cross-rates dashboard, the goal wasn’t just to deploy another static web page. Anyone can vibe-code a front-end converter in under 10 minutes. Instead, the real goal was to build and test a reusable edge caching and gateway blueprint on Tencent EdgeOne Makers that could sit in front of heavy APIs or regional services, protect upstream sources, and deliver sub-30ms response times globally.

Here is an honest breakdown of the architecture, the day-to-day developer experience with EdgeOne, and real multi-region benchmark results.

1. The Need of an Edge Gateway

Many data sources (such as financial feeds, weather data, or custom backend services hosted on a single origin) are geographically centralized. Direct client-to-origin fetches present three major issues:

1. Quota & Rate-Limit Exhaustion: Unchecked client requests directly hitting a rate-limited upstream API can quickly get your application blocked.
2. Cascading Failures on Outages: If the upstream source experiences a hiccup, a naive client-side application breaks immediately.
3. Regional Latency Penalties: A user querying a European or Southeast Asian origin from across the globe suffers 200ms+ round-trip delays purely due to fiber distance and TLS handshakes.

Rather than scheduling brittle daily CI/CD rebuilds (which fail if the provider is down during build time) or maintaining costly server-side proxies, a dynamic edge layer acts as a self-healing perimeter shield.

2. Dual-Layer Ingress Pattern

The architecture separates static delivery from dynamic edge caching using EdgeOne Pages, Serverless Edge Functions, and Edge Key-Value (KV) Storage.

flowchart TD
    Client["Client Browser"] -->|HTTP/HTTPS Ingress| EdgePOP["Edge CDN POP Cache<br/>(L1 RAM Memory)"]
    
    EdgePOP -->|"Cache Hit (0ms Compute, <30ms TTFB)"| Client
    EdgePOP -->|"Cache Miss / Cold Node"| IngressCheck{"Ingress Domain Validation<br/>(Origin & Referer Check)"}
    
    IngressCheck -->|"Unauthorized Host"| Block["HTTP 403 Forbidden"]
    IngressCheck -->|"Authorized Host"| EdgeFunc["Edge Function /api/rates<br/>(V8 Serverless Runtime)"]
    
    EdgeFunc -->|Query Persistent Layer| EdgeKV[("Edge KV Store<br/>(L2 Persistent Cache)")]
    
    EdgeKV -->|"Fresh (Date.now <= expiresAt)"| ReturnKV["Return Cached Payload + Cache-Control"]
    ReturnKV --> EdgePOP
    
    EdgeKV -->|"Expired / Missing"| Upstream["Fetch Upstream Source API"]
    
    Upstream -->|"Fetch Success"| SaveKV["Async Put L2 KV<br/>(Update Cache Key)"]
    SaveKV --> ReturnFresh["Return Fresh Payload"]
    ReturnFresh --> EdgePOP
    
    Upstream -->|"Upstream Outage (Circuit Breaker)"| StaleKV["Serve Stale L2 Cache<br/>(meta.stale = true, s-maxage=300)"]
    StaleKV --> EdgePOP

Ingress Domain Validation

To prevent unauthorized hotlinking and quota abuse on the Edge Function, the ingress handler inspects incoming request metadata (Origin and Referer). Unauthorized clients are rejected at the edge with a fast 403 Forbidden response before triggering downstream compute cycles.

3. Caching Strategy

To eliminate compute costs on repeated requests while maintaining total fault tolerance, the gateway uses a two-tier caching topology:

sequenceDiagram
    autonumber
    actor Client as Client Browser
    participant POP as Edge CDN POP (L1 RAM)
    participant Edge as Edge Function Ingress
    participant KV as Edge KV Store (L2)
    participant Upstream as Upstream Data Provider

    Client->>POP: GET /api/rates
    alt L1 POP Cache Hit
        POP-->>Client: HTTP 200 (Served directly from POP RAM)
    else L1 POP Cache Miss
        POP->>Edge: Invoke Edge Function
        Edge->>KV: GET cached_rates
        KV-->>Edge: Return payload + expiresAt timestamp
        Note over Edge: Check: Date.now() > meta.expiresAt
        
        alt Data Still Fresh
            Edge-->>POP: HTTP 200 (s-maxage=ExpiresAt)
            POP-->>Client: HTTP 200
        else Cache Expired / Revalidation Triggered
            Edge->>Upstream: Fetch latest data
            alt Upstream Healthy
                Upstream-->>Edge: Fresh JSON response
                Edge->>KV: PUT updated cached_rates (Async)
                Edge-->>POP: HTTP 200 (Fresh payload)
                POP-->>Client: HTTP 200
            else Upstream Down / Rate-Limited (Circuit Breaker)
                Note over Edge: Catch Error! Trigger Circuit Breaker
                Edge-->>POP: HTTP 200 (Stale payload, meta.stale=true, s-maxage=300)
                POP-->>Client: HTTP 200 (Uninterrupted user experience)
            end
        end
    end

Ephemeral POP RAM Cache (L1)

Configured via EdgeOne Rule Engine policies to respect Cache-Control: public, s-maxage=86400, max-age=300. Once an edge POP fetches data, subsequent visitors from that metropolitan area are served straight from edge memory in 5ms to 25ms, costing zero function execution quota.

Globally-Replicated Edge KV (L2)

If a user hits a cold edge POP, the Edge Function checks the globally replicated Edge KV database rather than making a slow origin network hop.

The Stateless Circuit Breaker

Instead of relying strictly on database-level TTL dropouts, cache expiration is evaluated deterministically in code (meta.expiresAt). If the upstream API goes down or returns an error, the function catches the failure, marks meta.stale = true, and returns the cached L2 data under a shortened CDN window (s-maxage=300). The end user experiences zero downtime.

4. 0ms User Interactivity

An edge gateway is only as fast as the client architecture consuming it. To ensure instantaneous responsiveness:

• The frontend makes a fetch to /api/rates on initial page load.
• Once received, the data matrix is stored directly in browser RAM and dispatched through custom window events:

  window.dispatchEvent(new CustomEvent('rates-updated', { detail: payload }));

• All cross-rate calculations, currency swaps, and table filters happen in the client’s memory engine in 0 ms, with no network round-trips during user interaction.

5. Developer Experience

Deploying on Tencent EdgeOne highlights a clear architectural design philosophy with distinct pros and cons.

The CNAME Onboarding Flexibility

Unlike platforms that force a full authoritative nameserver (NS) takeover of your root domain, EdgeOne supports a clean CNAME (Partial Zone) setup. You keep your existing DNS provider and point specific records to EdgeOne. This is a huge practical advantage if you manage infrastructure where handing over an entire DNS zone is restricted.

“Site-as-a-Container” Console Philosophy

EdgeOne groups infrastructure under a dedicated site container. When configuring a domain, your DNS records, Rule Engine, Cache Rules, WAF, and Edge Functions all live inside that single workspace.

• Advantage: Zero cross-site blast radius. You cannot accidentally modify a caching policy or WAF rule that breaks another project. Everything is cleanly siloed.
• Trade-off: The deep-nested menu structure increases click depth. Global search bars struggle to index settings buried several tiers down within a site container, requiring manual navigation through the sidebar.

6. Global Latency Benchmarks

To verify the real-world latency distribution, multi-region synthetic benchmarks were run using the Globalping API across 7 representative global locations.

The elevated TTFB observed for US static targets reflects cold L1 POP cache misses triggering origin pulls, which normalize to sub-30ms steady-state delivery once the edge nodes are primed.

Global Benchmark Timing (Warm L1 Cache State)

Location	DNS Resolution	Handshake (TCP+TLS)	Server (TTFB)	Total Duration
Brazil (São Paulo)	908 ms	10 ms	5 ms	923 ms
Germany (Frankfurt)	184 ms	23 ms	12 ms	219 ms
Indonesia (Jakarta)	39 ms	21 ms	13 ms	73 ms
Singapore	121 ms	44 ms	22 ms	187 ms
United States	140 ms	56 ms	29 ms	226 ms
Japan (Tokyo)	247 ms	103 ms	57 ms	407 ms
Australia (Sydney)	137 ms	267 ms	143 ms	547 ms

Key Benchmark Takeaways

• Once the edge POP cache is warm, server response time (TTFB) consistently hits 5 ms to 29 ms across South America, Europe, Southeast Asia, and North America.
• The elevated total times in synthetic probes (such as Brazil’s 908ms DNS lookup) reflect cold recursive resolver lookups by testing nodes. For real-world browser traffic, local resolver caching brings DNS lookups down to 1 ms – 2 ms.

Summary

Setting up a dual-layer edge gateway with Tencent EdgeOne Makers demonstrates how edge platforms can do far more than serve static HTML. By combining L1 POP RAM caching with persistent Edge KV and code-level circuit breakers, you get a dependable architecture that shields upstream APIs from quota exhaustion, survives third-party outages, and serves global requests with sub-30ms server latency.