Working with Edge KV Storage

FastEdge provides distributed edge KV storage that lets you read and write data from any edge location worldwide. Unlike traditional centralized databases, edge KV stores data close to users — reads are served from the nearest PoP, making them extremely fast regardless of where the data was written.

This post covers Working with Edge KV Storage — a foundational pattern for stateful edge applications.

How It Works

Store and retrieve key-value data at the edge. Perfect for config, feature flags, and session data distributed globally.

Edge KV storage is eventually consistent. Writes are propagated asynchronously across the global edge network. This means a write in London might take a few hundred milliseconds to be readable in Sydney — but local reads (from the same PoP) are immediate.

Implementation

Here is a complete example of reading and writing to edge KV storage in Rust:

use fastedge::{
    body::Body,
    http::{Request, Response, StatusCode, Error},
    kv_store::{KvStore, StoreType},
};

#[fastedge::http]
fn main(req: Request<Body>) -> Result<Response<Body>, Error> {
    // Open the default KV store
    let store = KvStore::open(StoreType::Default)?;

    // Read a value
    let counter: u64 = store
        .get("page_views")
        .and_then(|v| v.parse().ok())
        .unwrap_or(0);

    // Increment and write back
    let new_count = counter + 1;
    store.put("page_views", &new_count.to_string())?;

    let body = format!("Page views: {}", new_count);
    Response::builder()
        .status(StatusCode::OK)
        .header("content-type", "text/plain")
        .body(Body::from(body))
}

Use Cases

Feature flags — enable/disable features globally without redeploying your worker
Session state — persist data across requests without a central database
Rate limiting — aggregate request counters across the edge network
Configuration — store per-tenant settings that update without code changes
Cache — store computed results close to users for sub-millisecond retrieval

Consistency Model

Edge KV is eventually consistent with read-your-writes semantics at the local PoP. If you write a value, subsequent reads from the same edge location will see the update immediately. Reads from other locations may briefly see the old value until the write propagates (typically 100-500ms).

Tip: For strongly consistent writes, write through to your origin database and use edge KV as a read cache. This gives you the best of both worlds: strong consistency at write time and edge-speed reads.