Topic 8.9
Key-Value Databases
In one line
DynamoDB/Redis-class stores: O(1) by key, insane scale, and the access patterns that justify them.
Think of it like this
A cloakroom at a wedding: you hand over your coat and get a numbered tag. Getting your coat back later is just 'tag number → coat', instant and simple, with no other questions asked.
Key ideas
- 01
Contract: get(k)/put(k,v) — everything else is apps' business.
- 02
DynamoDB: partition key + optional sort key = built-in, automatic sharding; GSI/LSI for secondary access.
- 03
Redis: in-memory with rich value types (strings, hashes, sets, sorted sets, streams) + TTL — s̶t̶o̶r̶e̶ cache + session + counter.
- 04
Sorted sets = leaderboards/feeds; streams = light queues; TTL = sessions; the 'cache with a pulse' profile.
- 05
Eventual vs strong: DynamoDB default is eventual reads (strongly consistent is opt-in and costs).
- 06
Interview line: 'this is a key-value access pattern: user preferences by user_id — DynamoDB/Redis, one get'.
Java / Spring map
- →
spring-data-redis (RedisTemplate, Bucket4j for rate limiting), AWS SDK DynamoDbClient.
Explain without notes
Leaderboard 'top 100 by score' — which Redis structure answers it without a scan?
Practice
Design session store (TTL), rate-limit counter, and a fan-out queue with redis structures.
Trade-offs
- ↔
Key-value wins by surrendering queries — every new access pattern is a new key design.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can spot the key-value pattern in a prompt and name the store.