Edge-Native APIs: Why Latency Matters More Than Features

Your feature flag check adds latency. Your metering call adds more. Your webhook scheduling adds more still.

Each one seems acceptable in isolation. Together, they compound. Do that a few times per page load, and you’ve added noticeable delay. Your users feel the difference.

Infrastructure latency compounds. Every external call you add makes every other call hurt more.

The Geography Problem

Traditional SaaS APIs run in one region. Maybe us-east-1. Maybe eu-west-1. If you’re lucky, they have a few regions and you can pick one.

Your users are everywhere. A user in Singapore hitting a feature flag API in Virginia pays a significant latency tax. Before any processing. Just physics.

You can cache aggressively, which helps for read-heavy patterns. But cache invalidation has its own latency. And some things—metering decrements, webhook scheduling—can’t be cached.

Edge Changes the Math

Cloudflare runs in 300+ cities. When Solenoid’s APIs run on Cloudflare Workers, “the server” is wherever your user is. Singapore user? Singapore edge. São Paulo user? São Paulo edge.

The difference isn’t optimization. It’s physics. Light travels faster when it doesn’t have to cross oceans. Edge deployment means your API calls stay local instead of round-tripping to a distant region.

Why This Matters for Infrastructure APIs

Not all APIs benefit equally from edge deployment.

High benefit:

• Feature flags: checked on every request, latency directly impacts UX
• Metering: often in hot paths, blocking user actions
• Authentication: every request pays this tax

Lower benefit:

• Billing APIs: called monthly, latency doesn’t matter
• Analytics ingestion: async, can be batched
• Webhook delivery: outbound, destination latency dominates

Solenoid focuses on the high-benefit category. The APIs you call on every request. The ones where latency actually matters.

The Durable Objects Advantage

Edge compute is easy. Edge state is hard.

Stateless Workers are straightforward—deploy code globally, requests route to nearest edge. But feature flags need state. Meters need state. Hash chains definitely need state.

Cloudflare Durable Objects solve this. Each object lives in one location but can be accessed from any edge. The first request routes to the nearest edge, which fetches from the DO’s location. Subsequent requests from that edge hit cache.

For Meter, this means:

• First balance check: slower (edge → DO → edge)
• Subsequent checks: fast (edge cache hit)
• Writes always go to the DO for consistency

For Gate, we use KV instead of DOs because flags are read-heavy. KV replicates globally, so reads are always edge-local. Write propagation takes 60 seconds, which is fine for flag changes.

Architectural Implications

Building for edge changes how you think about state.

Accept eventual consistency where possible. Gate flags propagate in 60 seconds. For most flag use cases, this is fine. If you need instant propagation, edge caching works against you anyway.

Design for locality. Meter uses one DO per user. That user’s requests consistently route to the same DO. Locality means cache hits. Cache hits mean low latency.

Push computation to the edge. Gate SDKs evaluate flags locally after syncing. The edge serves the config; your code does the evaluation. Zero latency for the actual check.

Minimize round trips. Meter’s decrement operation checks balance and decrements atomically. One call, not two. At edge latencies, this is fast. At cross-region latencies, combining calls saves real time.

The Vendor Lock-In Question

“If I build on Cloudflare, am I locked in?”

Sort of. Workers have a specific API. Durable Objects are Cloudflare-only. Migrating to AWS Lambda or Vercel Edge would require rewriting.

But consider what you’re locked into with alternatives:

• Self-hosted Redis: locked into Redis protocol, operational model
• AWS services: locked into AWS APIs, regions, pricing model
• Other SaaS: locked into their API, uptime, pricing changes

All infrastructure choices have switching costs. The question is whether the benefits justify them. For latency-sensitive infrastructure APIs, edge deployment benefits are substantial.

If Cloudflare becomes unacceptable, you’d rewrite. But you’d probably rewrite anyway to escape any vendor. The edge advantage is worth the theoretical lock-in.

When Edge Doesn’t Matter

Be honest about when this doesn’t apply:

Batch processing: If you’re processing webhooks from a queue, edge latency is irrelevant. The work happens async.

Internal services: If your API only serves your own backend in one region, edge deployment adds complexity without benefit.

Low-traffic applications: At 100 requests/day, optimizing latency is premature. Focus on shipping features.

Latency-tolerant use cases: Analytics, reporting, admin dashboards—users expect these to take a moment.

Solenoid makes sense when you’re calling infrastructure APIs in user-facing hot paths at meaningful scale. If that’s not you, a regional API is fine.

Measuring the Difference

Don’t take our word for it. Measure from your actual user locations.

# From different regions, measure latency
for i in {1..100}; do
  curl -w "%{time_total}\n" -o /dev/null -s \
    https://gate.solenoid.systems/v1/gate/config \
    -H "Authorization: Bearer sm_your_key"
done

Compare to your current feature flag or metering provider. The numbers speak for themselves.

The Compound Effect

Back to where we started. If you’re calling three infrastructure APIs per request:

Traditional (single region): Cross-region round trips add up. Three API calls to a distant region means three times the latency tax.

Edge-native: Local calls stay fast. Three API calls to the nearest edge add minimal overhead.

The difference compounds with every request. At scale, edge deployment saves meaningful amounts of user-facing latency.

Latency matters. Edge makes it smaller. The math is straightforward.