# The Edge Computing Playbook — What to Run at the Edge (and What Not To) URL: https://www.devopsness.com/blog/edge-computing-playbook-what-to-run-at-the-edge Author: Kiril Urbonas Published: 2026-07-14 Updated: 2026-07-14 Categories: Cloud Tags: Serverless, Performance, Cdn, Edge, Cloudflare Summary: The edge is fast because it's constrained. This is the decision map for what belongs at the edge, what belongs at origin, and how compute, data, caching, and auth fit together. --- # The Edge Computing Playbook — What to Run at the Edge (and What Not To) The edge is fast for one reason: your code runs in a data center a few milliseconds from the user instead of one a few hundred milliseconds away. That speed comes with constraints. Small CPU budgets, no long-lived connections, limited runtimes, and data that lives somewhere else. Getting value from the edge is mostly about knowing which work fits inside those constraints and which work should stay at origin. This is the map. It ties together the moving parts (compute, data, caching, auth, observability) and points to the deep dive for each. Use it to decide where each piece of a request should run. ## What the edge is good at Edge functions shine at short, stateless, per-request work that benefits from being close to the user: - **Routing and rewrites**: A/B tests, feature flags, geo-based redirects, request normalization. This is the sweet spot for [Vercel edge middleware](/blog/vercel-edge-middleware-patterns-auth-ab-testing). - **Auth checks**: validating a signed token before a request ever reaches origin, covered in [edge auth without origin round-trips](/blog/edge-auth-validating-jwts-without-origin-round-trips). - **Caching and cache logic**: deciding what to serve from cache, with patterns like [stale-while-revalidate](/blog/edge-caching-stale-while-revalidate) and disciplined [cache invalidation](/blog/cdn-cache-invalidation-strategies). - **Personalization at the CDN**: small transforms on cached HTML per user or region. - **Streaming responses**: starting to send HTML while the rest is still assembling, via [streaming SSR at the edge](/blog/streaming-ssr-at-the-edge-rsc-and-html-streaming). ## What the edge is bad at The same constraints that make it fast make some work a poor fit: - **Heavy compute**: edge runtimes cap CPU time per request (often tens of milliseconds). Image processing, large crypto, or big data transforms belong at origin. The exact ceilings are covered in [edge runtime limits](/blog/edge-runtime-limits-what-you-cant-do-at-the-edge). - **Anything needing a full Node runtime**: many npm packages assume Node APIs the edge doesn't have. - **Chatty database access**: a function 5ms from the user but 120ms from your database is slower than one that runs next to the database. This is the single most common edge mistake. ## The data problem is the whole game Compute at the edge is easy; *data* at the edge is the hard part. If your edge function has to reach back to a single-region primary database, you've moved the compute closer to the user but left the slow part where it was. The answer is to move data outward too: - **Edge databases** replicate reads to the PoPs. See [edge databases for low-latency apps](/blog/edge-databases-for-low-latency-apps) and the [Turso vs Cloudflare D1](/blog/turso-vs-cloudflare-d1-edge-sqlite) comparison. - **Edge object storage** like [Cloudflare R2 vs S3](/blog/cloudflare-r2-vs-s3-egress-free-object-storage) keeps assets close and egress cheap. - **Stateful coordination**: when you need a single authoritative place to serialize writes (counters, rooms, locks), [Durable Objects](/blog/cloudflare-durable-objects-stateful-edge) give you one addressable instance instead of a race across PoPs. The rule: read-heavy, latency-sensitive data wants to be replicated to the edge; write-heavy or strongly-consistent data wants a single home, with the edge reaching it only when it must. ## How requests actually reach the edge Before any of this runs, the network has to route the user to the nearest point of presence. That's anycast plus smart placement, explained in [anycast and geo-routing](/blog/anycast-and-geo-routing-nearest-pop). It's worth understanding because "the edge" isn't automatically the closest edge. Placement and routing decisions matter, especially for the data tier. ## Platform choice The two dominant platforms make different trade-offs. The head-to-head that started this cluster, [Cloudflare Workers vs Vercel Edge](/blog/cloudflare-workers-vs-vercel-edge-a-latency-cost-comparison-2026-04-22), covers latency and cost; the newer [Workers vs Lambda@Edge](/blog/cloudflare-workers-vs-lambda-at-edge) comparison covers the AWS angle. For classic serverless where cold starts dominate, see [serverless cold starts](/blog/serverless-cold-starts-measuring-and-fixing-lambda) and [CloudFront + Lambda@Edge](/blog/edge-computing-aws-cloudfront-lambda-edge). ## Don't forget observability Edge functions run in hundreds of locations, which makes debugging harder, not easier. You need logs, traces, and metrics that aggregate across PoPs, covered in [observability for edge functions](/blog/observability-for-edge-functions-logs-traces-metrics). Skipping this is how teams end up with a fast site they can't troubleshoot. ## The call we'd make Push the request-shaping work (routing, auth, caching, personalization, streaming) to the edge, and keep heavy compute and authoritative writes at origin. Then solve the data tier deliberately: replicate reads outward, keep strong-consistency writes in one place, and reach for Durable Objects only when you need coordination. Start with one thing, auth or caching, measure the latency win, and expand from there. Each linked guide is a concrete next step; the constraints are the feature, not the bug.