[IgorPartola]

If you think of it as a cache, yes. If you think of it as another data layer then no.

For example, let’s say that every web page your CMS produces is created using a computationally expensive compilation. But the final product is more or less static and only gets updated every so often. You can basically have your compilation process pull the data from your source of truth such as your RSBMS but then store the final page (or large fragments of it) in something like MongoDB. In other words the cache replacement happens at generation time and not on demand. This means there is always a cached version available (though possibly slightly stale), and it is always served out of a very fast data store without expensive computation. I prefer this style of caching to on demand caching because it means you avoid cache invalidation issues AND the thundering herd problem.

Of course this doesn’t work for every workflow but I can get you quite far. And yes this example can also be sort of solved with a static site generator but look beyond that at things like document fragments, etc. This works very well for dynamic content where the read to write ratio is high.

[lemmsjid]

Quite agree, this is how I explain it to people. When you think of cache as another derived dataset then you start to realize that the issues caches bring to architectures are often the result of not having an agreement between the business and engineering on acceptable data consistency tolerances. For example, outside the world of caching, if you email users a report, and the data is embedded in the email, then you are accepting that the user will see a snapshot of data at a particular time. In many cases this is fine, even preferred. Sometimes not, and instead you link the user to a realtime dashboard instead.

Pretty much every view the user sees of data should include an understanding as to how consistent that data is with the source of truth. Issues with caching (besides basic bugs) often come up when a performance issue comes up and people slap in a cache without renegotiating how the end user would expect the data to look relative to its upstream state.

[hinkley]

The cache is an incomplete dataset by definition. It’s not a data set, it’s a cache of a data set. You can never ensure you get a clean read of the system state from the cache because it’s never in sync and has gaps.

[IgorPartola]

What about materialized views? CPU cache? Only the Sith deal in absolutes :)

[hinkley]

CPU cache means that the same value read twice will return the same value. Some exceptions for NUMA, and mu[tiple threads. But two reads of a cache cache make no such guarantees.

There is a vast number of undiagnosed race conditions in modern code cause by cache eviction in the middle of 'transactions' under high system load.

[hinkley]

No.

It’s not a data layer, it’s global shared state. Global shared state always has consequences. Sometimes the consequences are worth the trouble. But it is trouble.

If you think about Source of Truth, System of Record, cache is neither of those, and sits between them. There’s a lot of problems you can fix instead by improving the SoT or SoR situation in that area if the code.

[convolvatron]

in particular, the database already _has_ a cache. usually its on the other side of the evaluation, at the block layer. which means that you have a pay a cost to get to it (the network protocol, and the evaluation).

if you use materialized views, that surfaces exactly what you want in a cache, except here the views consistency with the underlying data is maintained. that's hugely important.

that leaves us with the protocol. prepared statements might help. now we really should be about the same as the bump-on-the-wire cache. that doesn't get us the same performance is the in-process cache. but we didn't have to sacrifice any performance or add any additional operational overhead to get it.

[IgorPartola]

Hard disagree. Having used the architecture I described in large practical deployments it works way better than what you are making it out to be. But I don’t know the domain you work in and your constraints so it is possible that for you it would not work.

[chamomeal]

I already typed a longer comment elsewhere that I don’t feel like reiterating but I agree with you. Caching is a natural outcome of not having infinite time and memory for running programs. Sometimes it’s a bandaid over bad design, but often it’s a responsible decision to take load off of other important systems

[cpursley]

Lost me at DumpsterFireDB as cache. But if the goal is to create an even worse architecture thats even harder to maintain, go for it.

[IgorPartola]

Sorry you lack the imagination to substitute your preferred data store into what I wrote. Hope it gets easier.

[cpursley]

I'll never have enough imagination to believe mongo is a good solution. Postgres has jsonb, vector type; redis is a fine-enough cache. Why use a known junk "database" when there are superior solutions and truly open source?

[IgorPartola]

I didn’t say you have to use it. I said you could. Or any other data store that fits your use case. I used a MongoDB instance back in 2012 in a serious production environment in this exact way and it worked flawlessly while Postgres was what gave us trouble (it had a bunch of features added since that would have made those issues disappear but back then it didn’t have built in replication for example.)

But again this is not an endorsement of MongoDB. I wouldn’t use it today but I did use it successfully and that company and tech stack sold for quite a bit of money and the software still runs, though I’m not sure on what stack. Again, if you are stuck on this one part of my comment… can’t help you.