Sponsored by
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a fun week!
Typing is a thing of the past
Typeless turns your raw, unfiltered voice into beautifully polished writing - in real time.
It works like magic, feels like cheating, and allows your thoughts to flow more freely than ever before.
With Typeless, you become more creative. More inspired. And more in-tune with your own ideas.
Your voice is your strength. Typeless turns it into a superpower.
Redis For Dummies
Redis is cool. That is all.
What is Redis?
Redis (REmote DIctionary Server) is an in-memory data-structure server. It can act like a key/value store, cache, counter store, session store, stream, queue-ish primitive, or primary database for some workloads. Strings are only one Redis data type—you also get hashes, lists, sets, sorted sets, streams, and more.
Why Redis is So BLAZINGLY Fast?
Redis keeps its working dataset primarily in RAM, which makes many operations extremely fast. It can also persist data to disk using snapshots and/or an append-only log, depending on configuration.
If it’s a key value structure why can’t I just do this?
my_dic = {}
my_dic["sloth"] = {"name": "hi", "email": "[email protected]"}Great question!
Process-local: a Python dictionary only exists inside that process, so another server or worker cannot automatically share it.
No built-in TTL/eviction policy: you would have to implement expiration and memory management yourself.
Concurrency semantics are your problem: individual operations may be safe in a given runtime, but multi-step updates still need synchronization if several threads/tasks can race.
No built-in replication/persistence/network protocol: Redis gives multiple processes and machines one shared service with optional durability and replication features.
Now you could get past these issues if you program them yourself, but guess what…
You could build those features yourself, but at that point you are building a cache/database service instead of your actual app.
Good job.
Common Use Cases
1. Caching (Most Popular)
import json
import redis
cache = redis.Redis(host="localhost", port=6379, decode_responses=True)
def get_user_profile(user_id):
key = f"user_profile:{user_id}"
cached = cache.get(key)
if cached is not None:
return json.loads(cached)
profile = database.get_user_profile(user_id)
cache.setex(key, 3600, json.dumps(profile))
return profileThis is the classic cache-aside pattern. The hard part comes later: invalidation. If the database changes while Redis still holds the old value, users can see stale data until you delete/update the cache entry or its TTL expires.
2. Session Storage
Redis is commonly used for server-side sessions because multiple app instances can share session state. In production, use a maintained session-store integration, generate the session secret from secure configuration, set cookie security options, and decide what happens if Redis is unavailable.
3. Real-time Features (Pub/Sub)
import redis
publisher = redis.Redis(host="localhost", port=6379)
subscriber = redis.Redis(host="localhost", port=6379)
pubsub = subscriber.pubsub()
pubsub.subscribe("notifications")
publisher.publish("notifications", "Hello, Redis!")
for message in pubsub.listen():
if message["type"] == "message":
print(message["data"])
breakImportant: Redis Pub/Sub is ephemeral. If a subscriber is disconnected when a message is published, it does not receive that old message later. For durable/replayable messaging, look at Redis Streams or a dedicated messaging system instead.
4. Rate Limiting
# Simplified fixed-window idea.
# Use an atomic script/transaction or a rate-limit library in production.
def rate_limit(client, user_id, limit=100, window_seconds=3600):
key = f"rate_limit:{user_id}"
with client.pipeline(transaction=True) as pipe:
pipe.incr(key)
pipe.expire(key, window_seconds, nx=True)
current, _ = pipe.execute()
return current Redis is useful here because every application instance can share the same counter. The counter update + expiration must be handled atomically enough for your algorithm; doing a bare INCR and then crashing before EXPIRE can leave a key with no TTL.
When to Use Redis?
Perfect for:
Caching frequently accessed or expensive-to-compute data
Shared session state
Counters, rate limits, locks, and short-lived coordination data
Leaderboards with sorted sets
Streams and event-processing workloads where Redis’s semantics fit
Skip for:
Workloads that need rich relational queries, joins, or relational constraints
Datasets whose cost/size makes primarily in-memory storage a poor fit
Cases where your durability, consistency, or query requirements are better served by another database
Redis can make the right slow things fast—but adding a cache also creates invalidation, memory, failover, and consistency problems you now own.
It is often paired with another primary database, but Redis can also be the primary store for workloads that fit its data model and durability tradeoffs. The important question is whether its persistence, replication, memory usage, and consistency behavior match your requirements.
In a world where users expect instant responses, Redis is often the difference between a snappy app and a slow one.
The performance gain can be addictive.
Once you see a 2-second lookup become 200ms, you’ll want to cache everything. Resist the urge. Measure first, cache the expensive path, choose a TTL/invalidation strategy, and monitor hit rate and memory usage.
If you want to keep learning
The 3 types of caches — see where Redis fits alongside browser and CDN caching.
Rate limiting explained — one of Redis’s most common production use cases for counters and request limits.
5 system design resources — go deeper on caching, databases, scalability, and architecture.
Thanks for the feedback 😁
Thanks to everyone who submitted!
AspenTheRoyal, NeoScripter, gcavelier, seansjlee, Suji-droid, s4ngyeonpark (private repo sorry!), and RelyingEarth87!
What Gives a Bad Mood?
Let’s say the greatest impact on someone's mood are: weather, meals, and sleep.
Your task is, given an array of sub-arrays of different values for:
[Mood, Weather, Meals, Sleep].
All values except for meals are 1-10 (1 = bad, 10 = good)
Meals are from 1-3
Determine which other variable has had the greatest impact on the mood.
Examples
greatestImpact([
[1, 1, 3, 10],
[1, 1, 3, 10],
[1, 1, 3, 10]
])
output = "Weather"
# Weather was always low but all others were high.
greatestImpact([
[10, 10, 3, 10],
[10, 10, 3, 10],
[10, 10, 3, 10]
])
output = "Nothing"
# Great days! all values were high.
greatestImpact([
[8, 9, 3, 10],
[2, 10, 1, 9],
[1, 9, 1, 8]
])
output = "Meals"
greatestImpact([
[10, 9, 3, 9],
[1, 8, 3, 4],
[10, 9, 2, 8],
[2, 9, 3, 2]
])
output = "Sleep"Notes
All values except for meals are 1-10 (1 = bad, 10 = good)
Meals are from 1-3
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
