Grokking the System Design Interview
Vote

0% completed

​

Caching

A cache is a small, fast store that keeps a copy of data you have already fetched. The next request for the same data is answered from the cache, so the slow work is not repeated.

The idea works because requests are not spread evenly. A small number of items are asked for again and again. A popular product page may be read a million times a day and changed once a month.

Two words describe what happens on every request.

A cache hit means the data was in the cache. A cache miss means it was not there

.....

.....

.....

Like the course? Get enrolled and start learning!
Willian Garbo Godoy Batista (Willggb)

Willian Garbo Godoy Batista (Willggb)

· 4 months ago

I think that write strategies should be separeted from topic "Cache Invalidation". The relations between the contents seems a little disconnected.

I

Idhant Haldankar

· a year ago

I wanted to confirm my understanding.

So in this type of cache update - Write-around cache - dont we also delete/purge the the record in cache layer? I wonder how will the client expect "cache miss" by simply updating the DB records.

Show 2 replies
Sam Levin

Sam Levin

· a year ago

This explanation seems a little bizarre to me.

"You should use cache-aside when you need caching but also need to ensure that a failure of the cache won’t take down your whole system"

What's an example of a situation where I'm ok with a cache failure taking down my whole system?

I also feel like you're glossing over how much complexity is involved in implementing a read-through cache. Hard to imagine how this layer wouldn't need to be aware of a lot of application logic.

R

rahul.raja412

· 3 years ago

Use read aside caching when optimizing read performance is the primary concern and use read-through caching when ensuring data consistency between the cache and backend storage is critical.

Choose write-through caching when data consistency is critical, write-back caching when write performance is paramount and some data loss or inconsistency can be tolerated, and write-around caching when write operations are infrequent or when certain data should not be cached.

F

F

· 4 years ago

If the system we are building is not large enough to have its own CDN, we can ease a future transition by serving the static media off a separate subdomain (e.g., static.yourservice.com) using a lightweight HTTP server like Nginx, and cut-over the DNS from your servers to a CDN later.

So how does this help exactly? Isn't this just sending requests to a back-end server? Is that idea that having all of your static media on a dedicated back-end somehow faster than having both your static stuff and other stuff on the same back-end?

N

Nikita Karpukhin

· 4 years ago

Write-around cache: This technique is similar to write-through cache, but data is written directly to permanent storage, bypassing the cache

So how does this solve cache invalidation problem?

Show 2 replies
C

Chris Drane

· 4 years ago

Under this scheme, data is written into the cache and the corresponding database simultaneously.

How is this done in practice? I know that DDID references XA being one approach. Are there others?

Reading Progress

0%