This week’s system design refresher: Top 9 Most Popular Types of API Testing (Youtube video) Is Passkey Shaping a Passwordless Future? How can Cache Systems go wrong? Big Endian vs Little Endian How do we incorporate Event Sourcing into the systems?
In 3. Cache breakdown. "Never expiring" technique works only if the cached element never changes.
If an element may be changed over time, we could retrieve it in advance just before the cache expires, and just replace the value in cache with this value read in background. It would prevent massive querying expired value.
If I were a theorist in System Design, I would introduce such concept in my work dubbing it "Background cached value pre-retrieving" pattern.
By the way, this technique can be used not only for hit values, but for any value. Just need to configure "Background pre-retrieving interval". In this case, it would just eliminate waiting even for one or two occasional readers for database query roundup.
> In 3. Cache breakdown. "Never expiring" technique works only if the cached element never changes.
We have avoided that by updating the "Never Expiring" key in cache every time underlying data is written in the system. For strong consistency writes, we will always update cache as soon as database returns success, and for eventual consistency writes, we send the cache update to queue (or accumulate cache writes where latest always wins, we did some trial and error per operation to determine accumulation vs queue).
In Passkey description: "A private key is generated based on the public key provided by the website. The private key is stored on the device."
Should not these key be generated in the opposite order? How is it possible to generate private key based on public key?
In 3. Cache breakdown. "Never expiring" technique works only if the cached element never changes.
If an element may be changed over time, we could retrieve it in advance just before the cache expires, and just replace the value in cache with this value read in background. It would prevent massive querying expired value.
If I were a theorist in System Design, I would introduce such concept in my work dubbing it "Background cached value pre-retrieving" pattern.
By the way, this technique can be used not only for hit values, but for any value. Just need to configure "Background pre-retrieving interval". In this case, it would just eliminate waiting even for one or two occasional readers for database query roundup.
> In 3. Cache breakdown. "Never expiring" technique works only if the cached element never changes.
We have avoided that by updating the "Never Expiring" key in cache every time underlying data is written in the system. For strong consistency writes, we will always update cache as soon as database returns success, and for eventual consistency writes, we send the cache update to queue (or accumulate cache writes where latest always wins, we did some trial and error per operation to determine accumulation vs queue).
In Cache Penetration, how do you know key does exist without checking database?
Suggestion to Cache Penetration need little more explanation i believe!