Read on our website
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a great week.
Design results
Option 1 is the winner!
More people preferred this!
I’m gonna refine it a bit and then I’ll start adding more visuals 😁
One more thing!
Recent newsletters have been getting clipped due to the length.
So I was thinking of potentially splitting the newsletter into 2 emails.
Email with only Advice + challenge
Email with only programming news + new/useful tools
Each email would be more in-depth with the content (more news, developer tools, etc.)
What do you think?
Should I split the newsletter into 2 emails
🦥 No sponsor this week, just vibes.
But if you want to reach 50,000+ developers, founders, and tech lovers who actually open their emails — this is the place.
The 3 Types of Caches
You know what’s interesting?
A cache is probably one of the easiest performance win you'll ever get.
But most developers don’t understand caching.
To be fair, a lot of tools automatically do it for you.
The problem with that is you probably don’t understand what should be cached or how it works.
Disclaimer: There’s A LOT more types of caches, but for programming & web dev, these are the most important ones for us.
Each layer caches different things at different locations.
What Is a Cache?
A cache is a faster copy of data or a previous result that you keep so future requests can avoid repeating expensive work. Cached data might live for milliseconds, minutes, months, or until you explicitly invalidate it.
Instead of fetching or recalculating from the original source every time, you reuse the cached copy while it is considered fresh enough.
You’re trading storage, freshness, and invalidation complexity for speed and lower load.
It’s like when you have multiple tabs open.
You leave them open because “you might need it.”
You don’t btw. Close those tabs…
1. Browser Cache
Where is this cache: User's browser
For What: HTML, CSS, JS, images
How it works: Server tells browser what to cache via HTTP headers:
Cache-Control: public, max-age=31536000, immutable
This tells compatible caches that the response can be reused for up to a year without revalidation while it is fresh. That kind of aggressive caching is best for versioned/content-hashed assets whose URL changes whenever the file changes.
Now next time when a user visits a website the browser checks if they have it.
If the cached response is still fresh, the browser can reuse it without downloading the full response again.
If it is stale, the browser may revalidate it with the server using validators such as
ETag/If-None-MatchorLast-Modified/If-Modified-Since.If the server says it has not changed, it can return
304 Not Modifiedinstead of sending the body again.
Cache Busting
Now what if you ship a new version of a long-cached asset?
That’s not good…
If the old URL is still considered fresh, clients can keep using the old file. This is why long-lived static assets normally use content hashes in their filenames.
Now you have to cache bust.
A common approach is to let your build tool generate a filename based on the file contents:
styles.css → styles.a1b2c3.css
When the file changes, its hash—and therefore its URL—changes. The HTML references the new URL, while the old asset can safely remain cached until it expires. Versioned paths or query strings can also work, but content-hashed filenames are a common production pattern for static assets.
styles.css → /v2/styles.css
https://example.com/styles.css → https://example.com/styles.css?v=2
Yeah it’s that simple.
Sloth that sounds annoying and miserable.
No it’s not? Just don’t write any mistakes.
Luckily, bundlers/frameworks and CDNs usually automate asset hashing and cache headers so you do not manually rename styles.v47-final-final.css every deploy.
It’ll still be annoying and have edge cases, but hey it’s automated…
Framework caching still has rules and tradeoffs, though. Learn what your framework caches, what invalidates it, and whether the cache lives in the browser, CDN, server process, or a shared data store before assuming “the framework handles it.”
2. Memory Cache
This is the type that everyone talks about the most.
Where is this cache: Inside an application process or a shared in-memory service such as Redis.
For What: Database results, API responses, calculations
How it works: Your application stores results under a cache key and defines when those results expire or get invalidated.
Without cache:
app.get('/data/:id', async (req, res) => {
const expensiveData = await getExpensiveData(req.params.id); // Pretend this exists
res.json(expensiveData);
});With cache:
const cache = new Map();
const TTL_MS = 60_000;
app.get('/data/:id', async (req, res) => {
const key = `data:${req.params.id}`;
const cached = cache.get(key);
if (cached && cached.expiresAt > Date.now()) {
return res.json(cached.value);
}
const expensiveData = await getExpensiveData(req.params.id);
cache.set(key, {
value: expensiveData,
expiresAt: Date.now() + TTL_MS,
});
res.json(expensiveData);
});This demo is process-local: every server instance gets its own Map, old entries need cleanup, and the cache can still serve stale data until its TTL expires. Shared caches such as Redis solve the “every process has a different cache” problem, but invalidation is still your problem.
Pretty easy to understand here. If you’re more curious about in-memory caching, read my Redis explainer.
3. CDN Cache
Where is this cache: CDN edge locations distributed geographically between users and your origin.
For what: Static assets and, when configured safely, cacheable HTML/API responses.
How it works: A CDN can store an origin response at an edge location. Later requests with the same cache key may be answered by the edge instead of traveling all the way back to the origin.
CDNs often use HTTP caching headers too, but a CDN cache and a browser cache are separate layers. They can have different cache keys, TTLs, purge rules, and shared-cache directives such as s-maxage.
A browser cache serves one user from their own device. A CDN edge cache can serve many users near that edge and reduce both origin traffic and network distance.
Illustrative example without a nearby cache: a user may need a longer round trip to the origin before receiving the response.
With a CDN cache hit: the response can come from a geographically closer edge and avoid work at the origin. The actual latency savings depend on geography, network conditions, payload size, and whether the response was really cacheable.
The annoying part: cache invalidation
Caching is easy when data never changes. Unfortunately, developers committed the crime of creating mutable data.
TTL: let the cached value expire after some amount of time.
Invalidate on writes: delete or update the relevant cache entry when the source data changes.
Version your keys/assets: changing the key or URL makes old cached values irrelevant.
Prevent cache stampedes: if a popular key expires, thousands of requests can all miss and hammer the database at once. Techniques include request coalescing, locks, jittered TTLs, and stale-while-revalidate.
The two questions to ask before adding any cache are: How stale can this data safely be? and what invalidates it? If you cannot answer those, congratulations—you have invented tomorrow’s bug.
Bonus: Hardware Caches (CPU, GPU, DSPs)
It’s a bonus because I know nothing about hardware and refuse to study this right now, but you can learn about it here.
Fun cache test you can do right now
Open DevTools → Network tab → disable cache button
Refresh your website and see how long it takes to load.
Try again but with the cache on.
If you want to keep learning
Redis explained — how production apps use an in-memory data store for fast caching.
5 system design resources — go deeper on caching, databases, scalability, and architecture.
Thanks to everyone who submitted!
Dependable Jobs Schedule
You’re given a number of jobs and a list of dependencies.
Each job is labeled from 0 to jobs - 1.
Each dependency [a, b] means job a can only start after job b is finished.
Return true if all jobs can be finished, or false if there’s a circular dependency.
finishAll(2, [[1, 0]])
output = True
finishAll(2, [[1, 0], [0, 1]])
output = False
## job 1 depends on job 0
## job 0 also depends on job 1
## → circular dependency, cannot complete either job
finishAll(3, [[1, 0], [2, 1]])
output = True
## job 0 → job 1 → job 2
## no cycles, all jobs can be finished in order
finishAll(1, [])
output = true
## only one job (0) with no dependencies
## → can be completed immediately
finishAll(11, [[6, 10], [4, 3], [9, 2], [2, 3], [6, 1], [2, 8], [10, 1], [10, 2], [5, 3], [0, 10], [7, 4], [6, 1]])
output = trueHow 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!
New silly video!
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.
