elasticache-redis

aws.elasticache.redis

In-memory data structure store: microsecond commands, sub-millisecond network reads, ~100k+ writes/sec per node. Fast because everything lives in RAM and runs on one thread.

Execution model

• Single-threaded: one command at a time, in order. Every individual command (and any Lua script) is atomic with no locks — this is why INCR counters and SET NX work without races.
• Flip side: one slow command (KEYS, huge ZRANGE, big Lua script) blocks every other client. Keep operations small; the single core is rarely the bottleneck otherwise.
• N+1 query patterns that ruin SQL are tolerable here — pipeline or MGET to pay one round trip instead of a hundred.

Sizing → config keys

• Redis is memory-bound, not CPU-bound. Pick nodeType by working-set size in RAM, not ops/sec — one node already handles ~100k ops/sec. cache.t4g.micro (default) is fine for small session/cache sets; move to cache.r7g.* when the dataset grows, before adding nodes.
• Memory full = writes rejected unless an eviction policy (e.g. allkeys-lru, sampled approximation) is set. If eviction would be wrong (data isn't reconstructible), Redis is the wrong store.
• numCacheNodes > 1 + multiAz: true buys: automatic failover (HA) and read replicas that multiply read capacity. Caveats: clients read primary by default (must enable replica reads), and replicas don't help write-hot keys.
• Single node is acceptable when contents are a pure reconstructible cache and a few minutes of cold-cache downtime is tolerable. Replication is async — a failover can drop the last acknowledged writes even with multiAz.
• transitEncryption: true and atRestEncryption: true always; private subnets only. Network edge from ecs/apprunner → redis.
• Beyond this config surface: cluster mode shards keys across 16,384 hash slots for >1-node write scaling — a different ElastiCache mode, not these knobs.

Data structures that change designs

• Strings/hashes: cache entries, sessions, counters (INCR). Hash = object with fields (e.g. product:123 → name, price).
• Sorted sets: leaderboards/top-K in log time (ZADD score, ZREMRANGEBYRANK to keep top N) and sliding-window rate limits (timestamps as scores: ZREMRANGEBYSCORE + ZCARD + ZADD in one Lua script). Fixed-window limit = INCR + EXPIRE-on-first-request, also as one Lua script.
• Streams: append-only log with consumer groups (XADD/XREADGROUP/XCLAIM) — good for modest work queues and event fan-out when Redis is already present; items can be redelivered, so make processing idempotent. Long retention/replay at scale is Kafka's job.
• Geospatial: GEOADD/GEOSEARCH (geohash in a sorted set) — proximity search without another datastore.
• Pub/Sub: at-most-once, in-memory broadcast; offline subscribers miss messages. Architecture in realtime-updates.md.