Use cases

Review these use cases to you help you choose the right platform, Akamai Functions, EdgeWorkers, or Combined Akamai Functions and EdgeWorkers.

Akamai Functions use cases

Choose Akamai Functions when you need to run application-level compute such as a microservice, an API backend, building an AI agent that integrates with AI inference calls (inference itself runs outside of functions), or any workload that benefits from WebAssembly's portability and performance. Akamai Functions is the right choice when you want to offload origin compute to the edge without the constraints of the CDN execution model.

Use case	Description
Edge API endpoints and microservices	A retail company's mobile app calls dozens of product, inventory, and pricing APIs, all of which currently live in a single origin data center. With Akamai Functions, these APIs are deployed as Spin components. API calls from Tokyo are served from Akamai's Tokyo region, calls from London from the nearest European region, dramatically reducing round-trip time compared to a centralized origin, with no infrastructure to manage.
Real-time data transformation and enrichment	A financial data provider delivers market data feeds to clients via API. Before delivery, each response needs to be filtered, normalized, and enriched with calculated fields based on the requesting client's subscription tier. This business logic is complex enough that it does not belong in the CDN layer, but latency-sensitive enough that it cannot afford an origin round-trip. Akamai Functions handles the transformation close to each client, returning enriched data in milliseconds.
Server-side rendering at the Edge	A news platform wants to serve server-side rendered pages for best performance. Akamai Functions hosts the rendering logic in lightweight frameworks like Preact , which assembles HTML from data APIs and templates, and delivers fully rendered pages from the nearest region. Origin infrastructure is reduced to data APIs alone, with all rendering offloaded to the edge.
WebAssembly-based image and media processing	A digital asset management platform needs to customize images on demand. These transformations are CPU-intensive and previously required dedicated image processing servers at the origin. With Akamai Functions, image processing runs in Wasm near the requesting user, with the processed image delivered directly. No origin involvement, no dedicated server fleet.
Stateful Edge applications with relational data	A SaaS platform wants to move a user preferences API closer to users globally. The existing implementation runs on application servers at the origin and reads and writes to a PostgreSQL database. The team migrates the API logic to an Akamai Function, connecting to a self-managed PostgreSQL instance. The Function handles the full CRUD lifecycle, reading preferences, validating updates, writing changes, while executing in the region nearest to the requesting user.
Session management with Redis	A high-traffic e-commerce platform needs low-latency session validation for authenticated users across a global user base. Session tokens are stored in a customer-managed Redis cluster, and each request must validate the token and retrieve session metadata before proceeding. An Akamai Function handles session validation close to the user, reading from Redis, checking expiry and permissions, and returning an enriched request context. Round-trip time to the Redis cluster is minimized by co-locating it with the nearest Akamai Functions region, keeping total session validation latency under 50ms.

EdgeWorkers use cases

Choose EdgeWorkers when you need to manipulate or route traffic at the HTTP layer, closest to the CDN delivery path. It's ideal for tasks where every millisecond matters and your logic is tightly coupled to request/response handling, caching behavior, or Akamai property configuration.

Use case	Description
Advanced request routing	A global retail platform needs to route traffic to different origin clusters based on a combination of user geography, product category, and time of day. Rather than relying on static DNS configurations or complex origin rules, EdgeWorkers evaluates the request at the edge and rewrites the hostname before the request leaves Akamai's network. The logic runs in microseconds at the nearest edge node, with zero round-trips to any central routing service.
A/B testing and feature flagging	A media company wants to test two different homepage experiences for 10% of users in North America without impacting performance. EdgeWorkers reads a cookie or assigns one using a deterministic hash of the user's IP, sets the appropriate variant header, and modifies the cache key to ensure each variant is independently cached. The entire bucketing decision happens at the edge, invisible to both the origin and the user.
Authentication and token validation	A streaming platform needs to validate tokens on every request to protected video content. Sending each request to an auth service at the origin adds unacceptable latency for a global audience. EdgeWorkers performs the token signature verification and claims validation directly at the edge, rejecting invalid tokens before the request consumes any origin resources. For tokens that need revocation checking, EdgeWorkers can consult EdgeKV, Akamai's edge-native key-value store, for a distributed blocklist.
Personalized caching and cache key customization	An e-commerce site serves product pages that are mostly cacheable except for a small personalized section showing a user's loyalty tier and local pricing. Rather than making the entire page non-cacheable, EdgeWorkers splits the cache key based on the user's cohort cookie. This lets Akamai cache multiple variants of the page. The result is high cache hit rates with personalization, eliminating the false choice between caching and personalization.
Dynamic header injection and security policy enforcement	A financial services company needs to ensure every response carries a strict set of security headers regardless of what the origin sends. Content Security Policy, Strict-Transport-Security, X-Frame-Options are all required. EdgeWorkers intercepts every response and enforces the header policy before delivery. This provides a consistent security posture without requiring changes to dozens of origin applications.
Geo-based content adaptation	A global news organization needs to serve different content based on user location, not just for language, but to comply with content licensing restrictions in certain countries and to surface locally relevant stories. EdgeWorkers evaluates Akamai's geographic metadata on the incoming request and rewrites URLs, sets targeting headers, or redirects users to region-specific origin clusters, all at the edge without origin involvement.

Combined use cases

Think of EdgeWorkers as the traffic controller. It decides how requests flow through Akamai's network. It can route requests, provide authentication at the edge, and offer light content transformations on the way through. Akamai Functions is the application server. It executes your business logic close to users without you managing the infrastructure behind it.

Used together, they form a powerful edge-native architecture. EdgeWorkers can make requests to Akamai Functions, or Akamai Functions can push data into the EdgeKV admin APIs, creating a fully edge-native stack from CDN to compute.

Use case	Description
Personalized content assembly	A media platform wants to deliver personalized content pages that are fast for both first-time and returning visitors, without sacrificing cacheability for the majority of content. EdgeWorkers intercepts the incoming request and evaluates the user's session cookie and geographic context to understand the personalization “depth”. For anonymous users and cohort-based personalization, it serves a fully cached default or variant page from Akamai's edge. For authenticated users, it leaves the request uncached. Cache misses for cohort-based personalized pages, and dynamic assembly of fully personalized pages are routed to an Akamai Function that retrieves the cohort information and/or user's preferences from a fast data store, selects a personalized content mix, and assembles a response. This forms a pattern similar to Edge Side Includes but with fully programmable logic. The personalized page is fast because the Function runs close to the user; the base page is fast because it is cached at the edge. Together they deliver a personalized experience with the performance profile of a cached page.
Multi-region failover and traffic shaping	A global SaaS platform operates origin infrastructure in three cloud regions and needs intelligent failover that responds to real-time health signals, not just static DNS TTLs. An Akamai Function runs as a lightweight health aggregator, periodically polling origin health endpoints and writing status updates to a shared data store such as EdgeKV. EdgeWorkers reads these health signals on every request and makes real-time routing decisions, shifting traffic away from degraded origins, distributing load based on current capacity, and adapting routing logic in response to latency measurements stored in EdgeKV. This creates a control loop where Akamai Functions gather and compute health intelligence and EdgeWorkers acts on it in real time at the request level, faster and with more granularity than a DNS-based failover mechanism could achieve.
Token revocation system	A global streaming provider wants to expand beyond the EdgeWorkers-based token revocation logic described above, and create a custom control plane to manage the list of revoked tokens. The revocation management API runs as a Akamai Function, maintaining data in a MySQL database as the source of truth for robust query capabilities. The Function reconciles revoked tokens to EdgeKV for fast access from EdgeWorkers. The control plane exposes the API not only over a traditional API described with an OpenAPI specification, but also as an MCP server to allow controlling the revocation list from an AI agent without a human operator.

Use case

Description

Personalized content assembly

A media platform wants to deliver personalized content pages that are fast for both first-time and returning visitors, without sacrificing cacheability for the majority of content.

EdgeWorkers intercepts the incoming request and evaluates the user's session cookie and geographic context to understand the personalization “depth”. For anonymous users and cohort-based personalization, it serves a fully cached default or variant page from Akamai's edge. For authenticated users, it leaves the request uncached. Cache misses for cohort-based personalized pages, and dynamic assembly of fully personalized pages are routed to an Akamai Function that retrieves the cohort information and/or user's preferences from a fast data store, selects a personalized content mix, and assembles a response. This forms a pattern similar to Edge Side Includes but with fully programmable logic. The personalized page is fast because the Function runs close to the user; the base page is fast because it is cached at the edge. Together they deliver a personalized experience with the performance profile of a cached page.

Multi-region failover and traffic shaping

A global SaaS platform operates origin infrastructure in three cloud regions and needs intelligent failover that responds to real-time health signals, not just static DNS TTLs.

An Akamai Function runs as a lightweight health aggregator, periodically polling origin health endpoints and writing status updates to a shared data store such as EdgeKV. EdgeWorkers reads these health signals on every request and makes real-time routing decisions, shifting traffic away from degraded origins, distributing load based on current capacity, and adapting routing logic in response to latency measurements stored in EdgeKV.

This creates a control loop where Akamai Functions gather and compute health intelligence and EdgeWorkers acts on it in real time at the request level, faster and with more granularity than a DNS-based failover mechanism could achieve.

Token revocation system

A global streaming provider wants to expand beyond the EdgeWorkers-based token revocation logic described above, and create a custom control plane to manage the list of revoked tokens. The revocation management API runs as a Akamai Function, maintaining data in a MySQL database as the source of truth for robust query capabilities. The Function reconciles revoked tokens to EdgeKV for fast access from EdgeWorkers.

The control plane exposes the API not only over a traditional API described with an OpenAPI specification, but also as an MCP server to allow controlling the revocation list from an AI agent without a human operator.