From f2046e2c9b1393fddd179edf31d08a389c35f9c0 Mon Sep 17 00:00:00 2001 From: Ronan Jouchet Date: Wed, 21 Aug 2024 14:17:17 -0400 Subject: [PATCH 1/2] =?UTF-8?q?=F0=9F=92=A1=20[patch]=20WriteThroughCache:?= =?UTF-8?q?=20cautionary=20JSDoc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Self-explanatory, as reminder of what we learned. --- src/lib/WriteThroughCache.ts | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/src/lib/WriteThroughCache.ts b/src/lib/WriteThroughCache.ts index 898780f..14efb3e 100644 --- a/src/lib/WriteThroughCache.ts +++ b/src/lib/WriteThroughCache.ts @@ -4,7 +4,31 @@ import { LocalCache } from './LocalCache'; /** - * Write-through cache, using Redis and a local LRU cache. + * Write-through cache, using Redis and a local LRU cache with aligned TTLs. + * + * **WARNING** if using this in a distributed app where cache consistency matters! + * Consider this case of an app with several servers/instances using WriteThroughCache: + * 1. Instance I1 sets key/value foo: bar (both local & redis) + * 2. Instance I2 gets value foo, populating its local cache with "bar" + * ----- At that moment, LocalCaches of I1 & I2 are aligned, foo: bar + * 3. Instance I1 deletes key foo (both local & redis) + * ----- At that moment, LocalCaches of I1 & I2 are *mis*aligned about foo! + * - I1 has nothing + * - I2 has "bar" + * + * -> This is fixable, e.g. using Redis pub/sub, to let clients subscribe to + * set/del events, and react with an eviction from their LocalCache. + * In the context we cachette maintainers got bitten by this, it made sense + * to simply abandon usage of WriteThroughCache, and switch the app with high + * consistency expectations from a WriteThroughCache to a RedisCache: + * +++: simpler, more consistent + * ---: a tolerable increase in Redis usage (CPU, network, latency) + * + * So, pub/sub remains unimplemented, but it would be a reasonable addition. + * API design consideration: set/dels maybe shouldn't *always* cause Redis + * publish (said differently, maybe not *all* set/dels should cause a + * LocalCache eviction, to limit pub/sub traffic explosion? Maybe, or maybe + * "pub/sub traffic explosion" is a non-concern? To be evaluated :) */ export class WriteThroughCache extends CacheInstance { From 5280a2400a19d97036ab75e7a2ce0520fa7b1a25 Mon Sep 17 00:00:00 2001 From: Ronan Jouchet Date: Wed, 21 Aug 2024 14:32:39 -0400 Subject: [PATCH 2/2] PR riviou Greg: phrasing --- src/lib/WriteThroughCache.ts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/lib/WriteThroughCache.ts b/src/lib/WriteThroughCache.ts index 14efb3e..94aa4d9 100644 --- a/src/lib/WriteThroughCache.ts +++ b/src/lib/WriteThroughCache.ts @@ -18,9 +18,9 @@ import { LocalCache } from './LocalCache'; * * -> This is fixable, e.g. using Redis pub/sub, to let clients subscribe to * set/del events, and react with an eviction from their LocalCache. - * In the context we cachette maintainers got bitten by this, it made sense - * to simply abandon usage of WriteThroughCache, and switch the app with high - * consistency expectations from a WriteThroughCache to a RedisCache: + * In the context where we cachette maintainers got bitten by this, it made + * sense to just abandon usage of WriteThroughCache, and switch the app with + * high consistency expectations from a WriteThroughCache to a RedisCache: * +++: simpler, more consistent * ---: a tolerable increase in Redis usage (CPU, network, latency) *