starter.wikiSearch⌘K

Data

Application Caching

Decide whether a reconstructable cache is justified, then choose its data model, consistency, failure, and operating boundary.

Recommendation

Do not add a cache until the origin bottleneck and invalidation rule are known.

A cache is a derived acceleration layer. Serverless Redis, provisioned Redis Cloud, and AWS-managed cache infrastructure fit different traffic and platform boundaries.13

For: Application teams with measured latency, throughput, rate-limit, counter, or origin-load problems

Main trade-off

Caching can reduce latency and origin load while adding invalidation, staleness, failure-mode, observability, and workload-cost complexity.135

Three managed cache routes

First prove that stale, missing, or evicted values are safe; then choose the smallest service model that fits the access pattern.

  1. Cache justification

    Identify the measured origin bottleneck, expected hit rate, latency goal, and why indexing or query work alone is insufficient.13

  2. Correctness on failure

    Define TTL, invalidation, stale reads, cache miss, eviction, service outage, stampede, and source-of-truth fallback.13

  3. Operations and topology

    Choose regions, persistence needs, memory, eviction, replication, monitoring, and capacity or request model.12

  4. Workload economics

    Model requests, stored bytes, transfer, memory floor, sustained throughput, and peak concurrency from production estimates.34

Cache service routes

All routes assume the data remains disposable or reconstructable and the application behaves correctly without a cache hit.

Bursty serverless Redis operations

Evaluate Upstash Redis.

Request-oriented access and Redis-compatible operations suit TTLs, counters, rate limits, and structured cache entries.

Verify: Sustained load, command gaps, regions, storage, bandwidth, eviction, and request economics must fit.123

Sustained traffic or broader Redis needs

Evaluate Redis Cloud.

Managed Redis breadth and provisioned capacity fit teams with Redis expertise or enterprise operational requirements.

Verify: Memory sizing, minimum plans, topology, persistence options, and operational configuration remain real responsibilities.134

The application needs an AWS-managed cache

Evaluate Amazon ElastiCache.

VPC integration and managed Valkey, Redis OSS, or Memcached can fit an application already operating inside AWS.

Verify: Engine choice, topology, node or serverless configuration, failover, regions, networking, minimum capacity, and AWS pricing remain explicit.135

Boundary: Use Key-Value Store when values are authoritative or durable. Use CDN for edge caching of HTTP content and assets. Do not cache data that cannot safely be stale or reconstructed.

Cache correctness before cache features

A fast happy path is not enough; the application must remain correct through expiry, eviction, misses, and outages.

API portability
Redis-compatible services and AWS engine choices create different migration, topology, and feature boundaries.12
Capacity model
Request-shaped billing and provisioned memory behave differently under sustained traffic and bursts.34
Failure behavior
Timeouts, regional incidents, stampedes, stale values, and origin fallback must be designed and observed.13
Persistence
A cache should not become an accidental source of truth because a service offers optional persistence.12

Official resources

Use the primary documentation to validate product boundaries, operating behavior, limits, and current commercial terms.

Sources

Official documentation supporting the decision routes and their boundaries.

  1. 1
    Upstash Redis getting started

    Upstash · Accessed Official

  2. 2
    Upstash Redis compatibility

    Upstash · Accessed Official

  3. 3
    Redis Cloud documentation

    Redis · Accessed Official

  4. 4
    Redis Cloud subscriptions

    Redis · Accessed Official

  5. 5
    Amazon ElastiCache documentation

    Amazon Web Services · Accessed Official