Redis

Question 1

reason you might not want to use Redis

Answer 1

durability. While there are some reasonable strategies for (using Redis’ Append-Only File AOF) to minimize data loss, you don’t get the same guarantees you might get from e.g. a relational database about commits being written to disk. This is an intentional tradeoff made by the Redis team in favor of speed, but alternative implementations (e.g. AWS’ MemoryDB) will compromise a bit on speed to give you disk-based durability.

Question 2

what is redis

Answer 2

self-described “data structure store” written in C. It’s in-memory 🫢 and single threaded 😱 making it very fast

Question 3

core structure

Answer 3

key-value store. Keys are strings while values which can be any of the data structures supported by Redis: binary data and strings, sets, lists, hashes, sorted sets, etc. All objects in Redis have a key.

Question 4

eviction policy

Answer 4

time to live (TTL) on each key. Redis guarantees you’ll never read the value of a key after the TTL has expired and the TTL is used to decide which items to evict from the server - keeping the cache size manageable even in the case where you’re trying to cache more items than memory allows.

Question 5

can be used as

Answer 5

Rate Limiting, Leaderboards Distributed Lock, Cache, Proximity Search, Event Sourcing, Pub/Sub

Question 6

issue

Answer 6

“hot key” issue

Question 7

hot key issue

Answer 7

our load is not evenly distributed across the keys in our Redis cluster

Question 8

technique to scale

Answer 8

redis cluster