The latency we don’t measure

One of the first metrics we ask a new client for is the average RTT from their users to their backend. The most common answer: “I’m not sure, but the site feels fast when I check from the office.”

The office, of course, is usually around the corner from the data center. Your real users are not.

We measured a client’s financial app with servers in us-east-1 (Virginia) and users mostly in the Dominican Republic, El Salvador, and Guatemala. Average RTT:

Origin	RTT to us-east-1	RTT to nearest edge
Santo Domingo, DR	78 ms	8 ms
San Salvador, SV	92 ms	12 ms
Guatemala City, GT	105 ms	15 ms
Bogotá, CO	95 ms	10 ms

Every interaction that requires a round-trip — auth, validation, lookup — pays that cost. A screen that fires 6 sequential requests spends half a second on latency alone.

Edge is not CDN

There’s common confusion. A CDN caches static responses near the user. Edge computing runs logic near the user. The operational difference:

• CDN: your HTML, CSS, images live at the edge. Your logic lives at origin.
• Edge: your HTML and the function that decides what HTML to serve live at the edge.

For mostly-read sites, a CDN may be enough. For interactive applications — auth, sessions, validation, personalization — the edge is where you win.

When yes

Edge shines when:

1. Your logic has little state. Functions that validate, transform, or route without maintaining heavy session.
2. Data access can be eventual. You have a read replica nearby or a cache that serves most of the traffic.
3. The user is far from your origin. This is the Caribbean and Central American condition for almost any US/EU deployment.
4. You want to serve multiple regions without replicating infra. A single edge-deployed function serves 300+ cities automatically.

Real cases where we applied it:

• ECF SSD API: every e-CF call goes to the nearest edge to the client, validates the XML, signs locally (without touching the client’s private key — the SDK handles that), and only travels to DGII from the nearest edge to the official endpoint. End-to-end average: <2s including ACECF.
• Content geolocation: a user in CR sees localized content without waiting for an origin to decide what to serve.
• A/B testing without flash: the bucket decision happens at the edge, not in the client — the user doesn’t see a flash of the wrong variant.

When no

Edge is the wrong answer when:

1. Your logic needs long transactions. Edge isn’t great at coordinating 12 atomic writes. For that, the origin.
2. Your session is large and changes a lot. If you need to rebuild 50 KB of state per request, the edge will cost more than it earns.
3. Your data lives in one place only. If your entire database is in us-east-1 and every edge request has to fetch it, you’ve reintroduced the latency you wanted to avoid.
4. Compliance demands strict geolocation. Some regulators require data not leave the country. The edge complicates this if you don’t choose your provider carefully.

Patterns that work

1. Edge as “front door”

Every request enters through the edge. Auth, rate limiting, A/B testing, redirects happen there. Only operations that need full state touch the origin.

// Edge Worker (runs in 300+ cities)
export default {
  async fetch(request, env) {
    const session = await validateJWT(request, env.JWT_SECRET)
    if (!session) return new Response('Unauthorized', { status: 401 })

    // 80% of requests resolve here
    if (request.url.includes('/api/profile')) {
      const cached = await env.CACHE.get(`profile:${session.userId}`)
      if (cached) return new Response(cached)
    }

    // The rest goes to origin
    return fetch(env.ORIGIN_URL, request)
  }
}

2. Cache with smart purge

Cloudflare KV or D1 as a regional cache. Specific invalidation beats global TTL.

// When the profile changes at origin, we purge from there
await fetch('https://api.cloudflare.com/.../purge', {
  method: 'POST',
  body: JSON.stringify({ keys: [`profile:${userId}`] })
})

3. Edge for validation, origin for writes

Validating the payload of a POST at the edge saves round-trips to the origin for invalid requests. The origin only sees what already passed the first barriers.

What you pay to move to the edge

Technical honesty:

• Cold starts: at the edge they’re less severe than on Lambda, but they exist. For <50ms latency, deploy your worker as a compiled artifact, not a dynamic bundle.
• Debugging: your stack trace is no longer on a server you control. You need structured observability from day one.
• Runtime limits: CPU time, memory, number of subrequests. Your “edge” logic can’t be the same as a server.
• State: the edge is stateless by design. If your app depends on holding state in RAM, you’ll suffer.

How to measure if it’s worth it

A simple metric before starting: time to first byte (TTFB) per region.

curl -w "%{time_starttransfer}\n" -o /dev/null -s https://your-app.com/api/health

Do it from a VPS in every country where you have serious users. Compare to what you measured in your office. If the difference is >100ms and your app makes multiple requests per interaction, the edge pays for itself.

If it’s only 20-30ms of difference and your volume is low, the edge probably isn’t your biggest lever. Optimize the origin first.

Close

The edge isn’t the answer to everything. But for a region like ours — where the average user is geographically far from the major data centers — it’s a tool that changes conversations. The difference between “the system feels slow” and “the system flies” is often the decision to move the logic instead of waiting for the cable.

— The SSD team