Edge functions and global latency for commerce sites

By Marco Lopes · Published March 16, 2025 · Cloud & DevOps

A commerce site can feel fast near its primary server and painfully slow everywhere else. Product pages hesitate, search results arrive late, and carts seem to pause before acknowledging a click. When every interaction crosses an ocean, even efficient application code starts with a disadvantage.

At Kordspace, we approach global performance as a systems problem rather than a hosting upgrade. As a remote collaborative software, AI, Web3, hardware, and design studio, we work across interfaces and infrastructure. For commerce, that means connecting what shoppers experience with where requests travel, where data lives, and how safely we can cache responses.

Edge functions can help, but they are not a universal shortcut. We need to put the right work close to shoppers while keeping authoritative transactions predictable.

Start with the request journey

Before choosing an edge runtime, we map a few essential journeys: opening a category, viewing a product, searching, adding an item to a cart, and completing checkout.

Each journey has a different latency budget and consistency requirement. A cached product image can come from a nearby CDN location. A stock reservation usually needs an authoritative inventory service. Treating both as equivalent “requests to accelerate” leads to disappointing architecture.

We inspect the full path: DNS lookup, connection establishment, CDN handling, application execution, database access, third-party calls, and browser rendering. Time to first byte matters, but it does not explain a page blocked by excessive JavaScript or an oversized hero image.

Our first deliverable is therefore a baseline, segmented by geography, device, route, and cache status. Without that baseline, we risk moving code around without improving the shopping experience.

Separate edge delivery from edge execution

A CDN and an edge function solve related but different problems.

A CDN stores reusable responses near users. An edge function executes logic at distributed locations, typically under tighter runtime limits than a conventional server. Neither automatically moves the database, search index, payment provider, or inventory system closer to the shopper.

That distinction matters. If an edge function immediately calls a database in one distant region, the request still pays for that journey. It may also gain an extra network hop compared with a direct origin request.

We use edge execution when it can finish useful work locally or avoid unnecessary origin traffic. Lightweight redirects, URL normalization, selected header changes, and routing decisions are good candidates. Complex business workflows with several dependent reads generally belong near their data.

The question is not whether we can run a handler at the edge. It is whether doing so shortens the critical path.

Use a Google Cloud-first foundation honestly

For a Google Cloud-first commerce platform, we often begin with a global external Application Load Balancer, Cloud CDN for eligible public responses, and Cloud Run for regional application services. Cloud Storage can serve versioned static assets through the delivery layer.

This is a globally accessible architecture, but Cloud Run services still execute in selected regions. A global endpoint does not make application execution happen at every CDN location. Likewise, deploying a function to a cloud region is not the same as deploying it across a distributed edge runtime.

We can place Cloud Run services in multiple regions and use supported load-balancing configurations to reach them. However, routing, health behavior, capacity, and data access need explicit design and testing. Multi-region application deployment alone does not guarantee healthy failover for the whole commerce system.

Where genuinely distributed request-time execution is necessary, we evaluate a dedicated edge platform or another provider’s offering alongside Google Cloud. We keep the boundary narrow so the core application remains portable and understandable.

Cache public commerce content before adding compute

For many storefronts, better caching is the highest-value first change.

We separate public catalog data from private session data. Product descriptions, editorial content, category navigation, and versioned assets are often reusable. Account details, cart contents, personalized discounts, and checkout responses are not safe shared-cache defaults.

For an explicitly public catalog response, a policy such as Cache-Control: public, max-age=60, s-maxage=300 can give browsers and shared caches different freshness windows. Those values are examples, not a recommendation for every catalog. We choose them according to how quickly content changes and what stale information would cost.

We define cache eligibility and bypass behavior deliberately, including what happens when requests carry authorization headers or session cookies. We do not assume the presence of a cookie automatically makes every CDN configuration safe.

A reliable cache policy needs an invalidation plan, too. Versioned asset URLs are straightforward; catalog changes may need targeted invalidation or bounded expiry. We avoid making emergency global purges the normal publishing workflow.

Treat the cache key as a security boundary

A response is reusable only when everyone sharing its cache key should receive the same representation.

Commerce makes this deceptively complicated. Language, currency, market, tax display, customer group, and experiments can all change a page. If our cache key ignores a meaningful difference, shoppers may see the wrong content. If it includes every cookie and query parameter, the cache may barely work.

We prefer explicit, bounded variants. A market-specific URL such as /gb/products/example is easier to reason about than a response whose meaning depends on several invisible cookies. Currency and language can follow the same principle when the product requirements support it.

We also normalize irrelevant tracking parameters where safe, and reject or constrain untrusted inputs that could create unlimited variants. We test the actual CDN behavior rather than assuming a Vary header covers every intended dimension.

Most importantly, we never let private account or cart content enter a shared public cache. Cache testing belongs in security review, not just performance tuning.

Put small, reversible decisions at the edge

Good edge logic has a small dependency footprint and an obvious fallback.

We might redirect an old product URL, normalize a trailing slash, choose a public storefront variant, or route an eligible experiment cohort. These operations can reduce origin work without becoming the source of truth for orders.

Location-based behavior needs restraint. IP-derived geography is an approximation, not a verified shipping destination or tax address. We can suggest a market, but we should let shoppers change it and preserve their explicit choice.

For experiments, we establish a stable assignment and align caching with the actual page variants. Otherwise, a cache can accidentally distribute one shopper’s experiment response to everyone.

We keep payment credentials, sensitive customer information, and complex authorization workflows out of casual edge middleware. Any token verification requires proper cryptographic checks, rotation handling, and bounded caching of verification material, not merely decoding a token and trusting its contents.

Keep transactional truth close to its data

Checkout rewards consistency more than architectural fashion.

We can show a cached product description while retrieving current availability separately. We can display an indicative price early while validating the payable amount on the server before an order is accepted. We should make those boundaries clear in both the API and interface.

Inventory reservations, promotion redemption, and payment operations need authoritative validation. Retrying them blindly can create duplicate effects. We use idempotency keys where supported and design our own order-processing boundaries to recognize repeated requests safely.

Read replicas may improve catalog access, but replication lag makes them unsuitable for some decisions. A recent stock update or account change may not yet be visible everywhere.

We therefore start with explicit ownership: which service decides the price, which commits inventory, and which records payment state? Once those responsibilities are clear, we optimize the surrounding reads without weakening the transaction.

Choose regions by dependencies, not maps alone

Regional placement should follow both shoppers and data.

If our application runs near European users but its database, search service, and commerce backend remain elsewhere, each page may trigger several long-distance calls. Parallel requests help only when those calls are independent. Sequential dependencies accumulate delay.

We first reduce chatty interfaces, batch suitable reads, reuse connections, and remove unnecessary calls. Then we consider regional read models, replicated public catalog data, or additional application regions.

On AWS, CloudFront Functions and Lambda@Edge offer different execution capabilities and constraints. On Azure, Front Door provides global delivery and routing, while application compute still requires deliberate placement. We do not treat these services as interchangeable with one another or with Google Cloud’s components.

Provider choice follows the workload, operational skills, compliance needs, and existing platform. We compare runtime limits, network access, deployment behavior, observability, and total cost before committing.

Design for failure and control the cost

Every dependency needs a deadline and a fallback appropriate to its role.

If recommendations time out, we can omit the widget. If inventory validation fails, we should not quietly accept an unverified order. Public content may tolerate stale delivery within a defined window; account information usually requires a different policy.

We bound retries, avoid retry storms, and make sure edge and origin layers do not independently repeat the same failing operation. Circuit breakers and rate limits can protect an overloaded backend, but they need realistic load testing.

Cost also follows the complete request path. We account for function invocations, cache misses, origin compute, logging, cross-region transfers, and provider egress. An inexpensive edge invocation can still trigger expensive downstream work.

We keep security enforcement explicit: protect origin access where the architecture supports it, validate forwarded headers at trust boundaries, and avoid logging sensitive request bodies.

Measure the rollout, not just the demo

We validate changes with real-user monitoring and synthetic journeys from the markets we serve. Synthetic checks expose regional availability problems; real-user data shows the effects of devices, networks, and browser behavior.

We track median and tail latency, cache-hit rates, origin error rates, and essential journey completion. Core Web Vitals remain useful, especially when backend improvements fail to translate into visible responsiveness.

Tracing should connect delivery, application, and downstream services without exposing personal data. We sample sensibly and label public cache outcomes so a latency improvement is not mistaken for faster origin code.

Rollouts should be incremental: one public route, one market, or one carefully bounded cohort. We keep a quick rollback path and compare equivalent traffic, rather than declaring success from a nearby laptop on a warm cache.

A short pre-launch checklist

• Classify routes as public, personalized, or transactional.
• Document cache keys, bypass rules, freshness, and invalidation.
• Verify where compute and every critical dependency execute.
• Test cross-market variants and private-data isolation.
• Set deadlines, safe retries, and degraded-mode behavior.
• Compare regional latency, errors, user experience, and cost.
• Confirm rollback and failover with realistic requests.

Build for the journey that matters

Edge functions are most useful when they remove work, shorten a request path, or make public content easier to deliver globally. They are least useful when they hide a distant dependency behind another layer. We aim for a storefront that feels responsive while keeping prices, inventory, and payments trustworthy.

If we can help plan that balance for your commerce platform, start a project with Kordspace. To explore how we connect infrastructure, software, and design, read our related services pages.