SYSTEM Cited by 2 sources
AWS ElastiCache¶
AWS ElastiCache is AWS's managed in-memory cache service, supporting the Redis and Memcached engines. Removes the operational burden of running Redis/Memcached clusters directly — patching, failover, read replicas, backups, multi-AZ — while keeping the engine semantics and client protocol the same. Typical uses: hot-path cache for application reads, fast serving tier for precomputed artifacts, rate-limit / counter storage, session storage.
Why it's mentioned here¶
Canva's Print Routing engine uses ElastiCache + Redis as the serving tier for per-region precomputed routing graphs:
- 6 ms retrieval in most regions, 20 ms for the largest shards.
- 99.999% availability (with read replicas).
- Source of truth lives elsewhere (relational DB) — losing ElastiCache means rebuild, not data loss.
See sources/2024-12-10-canva-routing-print-orders and systems/canva-print-routing.
Seen in¶
- sources/2024-12-10-canva-routing-print-orders — Canva Print Routing's graph serving tier.
- sources/2026-04-21-figma-figcache-next-generation-data-caching-platform — Figma FigCache fleet fronts a large pool of ElastiCache Redis clusters with varying isolation requirements, durability expectations, criticality characteristics, and traffic volumes. FigCache absorbs ElastiCache operational events (node failovers, cluster scaling activities, transient connectivity errors) as zero-downtime background operations — shard failovers run liberally and frequently across the entire footprint as live resiliency exercises. Canonical deployment shape: ElastiCache is the durable / ops-managed Redis; the in-house proxy tier is the unified data plane in front.
Related¶
- redis
- systems/figcache — Figma's proxy tier in front of ElastiCache
- patterns/caching-proxy-tier — the architectural pattern for fronting ElastiCache at scale
- systems/canva-print-routing
- patterns/async-projected-read-model