Level 3 cache

[Jackpieking]

Hi all, i know this lib only support 2 layer cache, but i want to add the 3rd layer that use sqlite for caching? Is this possible and if it is, are there any docs about this?

Thanks

[jodydonetti]

Hi @Jackpieking , the idea is that there are 2 clearly defined levels:

• L1: memory, always there, cannot fail
• L2: distributed (or more precisely, "out of process"), may not be there and/or fail (eg: restarts, shutdown, network issues, etc)

This design allows FusionCache to have a clear behavior, without things like "we have 2 distributed levels, 1 failed, the other didn't: what should we do?" kind of things. This, in turn, allows FusionCache to have features like smart timeouts, auto-recovery, etc.

Now, because of this, in theory 3 levels would not be ideal.

But.

You can create your own impl of IDistributedCache or IMemoryCache and pass that to FusionCache!

Inside of it you need to make the 2 calls to MemoryCache/SQLite or SQLite/Redis, basically an adapter approach.

However, you need to decide some things, like:

• how you want the execution to be: sequentially? in parallel? etc
• what to do in case of failures: retries? only 1 fail equals both failed? etc
• priority for reads: data is in 2 of them, which one takes priority?

Having said that, yeah: you can actually do that.

I made a quick experiment some time ago, and it worked pretty well: having said that, I did not use it in production, so some extra testing before going live may be necessary.

If you try with this approach, please let me know!

Hope this helps.

[Jackpieking]

Thanks, and i want to ask one more question

How do you implement the request coalescing. I really want to implement this with normal requests to web api

[jodydonetti]

With locking, but not a global one of course but one lock per-key.

Regarding web api: if you mean the db (or similar) call in the request, you can use FusionCache of course.
If you mean the entire request api call itself, that is usually done with output caching.

In that case the default implementation is in-memory, but as soon as FusionCache V2 will be out (we're talking one or two weeks!) I'll create a FusionCache-based implementation of output cache 😬

[Jackpieking]

Ohhhhh yes i want to apply to entire request and i got the keyword, i did not know output caching can do that.

Many thanks 😁😁

[jodydonetti]

Oh btw, I forgot to ask... why the need? I mean, just to be sure I'm not missing anything and to help understand if it's really necessary, why the extra level?
If it is to help with with cold starts, L2 can already do that.
And if it's instead of a real distributed level (to avoid having to manage a Redis instance, for example), you can use SQLite as the distributed level.

One last thing: if you find my answer useful can you mark it as the answer? Thanks!

[Jackpieking]

No because i think sqlite is better than postgres when come to querying, so i think like

in memory -> redis -> sqlite -> postgres

but then i realize my postgres only have 3gb ram, cannot do anything much, so i am going to upgrade postgres to 20gb ram with 4vcpu and tune the pg a little bit to have a better performance

But thanks for your response anyway, it really helps me out😁😁