Edge-First Architecture with Cloudflare and Vercel

“Edge computing” has become a marketing term broad enough to mean almost anything. But behind the buzzword is a genuinely useful architectural pattern: running your application code close to your users, reducing round-trip latency from hundreds of milliseconds to single-digit milliseconds.

Here’s how we think about edge architecture, when to use it, and what the actual tradeoffs are.

What “Edge” Actually Means

Traditional web servers run in a single region — typically us-east-1 or wherever your cloud provider defaults. A user in Singapore requesting your US-based API adds 200–300ms of round-trip latency before a single line of your code runs.

Edge computing distributes your code across dozens or hundreds of Points of Presence (PoPs) globally. When that Singapore user makes a request, it’s handled by a server a few milliseconds away.

The two platforms we use most:

• Cloudflare Workers: V8 isolates running at 300+ PoPs globally, 0ms cold start
• Vercel Edge Functions: Built on Cloudflare Workers with Next.js/Astro integration

The Cold Start Problem (That Doesn’t Exist Here)

Traditional serverless (AWS Lambda, etc.) has a cold start problem: the first request after idle time spins up a container, adding 500ms–2s of latency. Edge runtimes use V8 isolates instead of containers — they start in under a millisecond.

This changes the calculus for API routes significantly. The reason to reach for a traditional server (to avoid cold starts) largely disappears with edge runtimes.

What Edge Runtimes Can’t Do

Edge runtimes run in a constrained environment. Understanding the constraints is essential:

No native Node.js modules. fs, child_process, path, and most Node.js built-ins are unavailable. You’re in a V8 environment with Web APIs (fetch, Request, Response, crypto, etc.).

No direct database connections. TCP connections to PostgreSQL, MySQL, etc. don’t work from Cloudflare Workers. You need an HTTP-based database driver (Neon’s HTTP driver, PlanetScale’s HTTP API, Turso’s edge client) or a connection pooler like Hyperdrive.

Limited execution time. Cloudflare Workers have a 50ms CPU time limit on the free plan, 30 seconds on paid plans. Long-running operations belong in traditional serverless or dedicated servers.

No filesystem access. Everything is in memory or fetched from external services.

Our Architecture Pattern

For applications that benefit from edge, we use this pattern:

User Request
     ↓
Cloudflare / Vercel Edge
  - Authentication (JWT validation)
  - A/B testing / feature flags
  - Request routing
  - Simple API endpoints (cached responses)
     ↓
Regional API (Node.js)
  - Complex business logic
  - Database queries (via connection pool)
  - Third-party API calls with retries
     ↓
Database (same region as API)

The edge layer handles latency-sensitive operations: auth, routing, and cacheable responses. Heavy compute stays in a traditional regional server.

Caching at the Edge

The most impactful use of edge computing is caching. Vercel’s CDN and Cloudflare’s cache both support fine-grained cache control headers.

For the Artisan Collective marketplace, product pages and search results are cached at the edge with a 60-second TTL. Cache invalidation happens via Cloudflare Cache API or Vercel’s revalidateTag. The result: most requests serve from cache in <5ms, eliminating database load for the vast majority of traffic.

// Astro page with edge caching
export const headers = {
  "Cache-Control": "public, s-maxage=60, stale-while-revalidate=600",
};

When NOT to Use Edge

Edge isn’t always the right choice. Cases where we don’t reach for it:

• Long-running jobs: Report generation, data processing, batch operations → use a queue and worker
• Complex database queries: Sub-50ms queries at the edge, but the database is still regional. If your query takes 100ms, edge saves the network hop but you’re still waiting
• WebSocket connections: Edge platforms are stateless request-response; for real-time, use a dedicated service like Ably or Pusher
• Applications with a single geographic user base: If all your users are in one region, co-locating with your database gives better results than edge

Real-World Impact

On FinFlow’s analytics dashboard, we moved authentication and user session validation to a Cloudflare Worker. Auth checks that previously added 180ms (US-East database round-trip for a Singapore user) now take 8ms. The actual data queries still hit the regional database, but the common case — validating a session and returning cached data — is dramatically faster.

Our Default Setup

For new projects in 2024:

• Static assets + CDN: Vercel or Cloudflare Pages
• API routes that can be edge: Vercel Edge Functions or Cloudflare Workers
• API routes that need Node.js: Vercel Serverless Functions (regional)
• Database: Neon (PostgreSQL with edge-compatible HTTP driver)
• Cache layer: Cloudflare Cache API or Vercel Data Cache

The goal is to serve as much as possible from cache or edge, and push complex computation to where it belongs: close to the data.

Conclusion

Edge computing is a real performance lever, not just marketing. The latency improvements for globally distributed users are significant, and the tooling has matured to the point where edge deployments are nearly as simple as traditional serverless.

The key is understanding the constraints. Design for the edge from the start — retrofitting an application that assumes Node.js APIs and direct database connections is painful. Start with the edge model and add regional compute where you need it.