3 ms·

Caching is for poor designs. Most "modern" designs only rely on cache for data distribution speed. Cache is an optimization.

hinkley 4y ago
> Caching is for poor designs. Caching is the death of design. People who like to make decisions and then studiously avoid ever looking at the consequences of their actions don't seem to notice that once caching is introduced, the data model in the system either stops improving or begins to unravel. It becomes very difficult to benchmark the system looking for design issues because the real cost of a cold cache is very difficult to measure. And the usual argument that we can turn off the cache for performance analysis doesn't hold water for more than a few months. Pulling the same data twice, three times, ten times in a given transaction are all about the same cost, and it gets me out of trying to figure out how to plumb new data through the sequence diagrams. I can just snatch values out of global state wherever, whenever, and as often as I need them. Once people give up and start doing that, you can't turn off the caches anymore. When you started it cut the cost of the lookup in half, or a third. Now it's four, or five, or sixteen, and that call is now over-represented in the analysis, hiding other, more tractable problems. You've settled for your broken design, but also cut the legs out from under any of the tools that can dig you out of the hole you've dug. Caches are just global state under a different name, but slathered in RPC issues.
romange 4y ago
Some valid business use-cases allow eventual consistency. Think of social apps, for example. FB and TW have excellent engineering teams and they built huge systems that rely on caching layers. Similarly, with gaming companies.
- dvt 4y ago
  Once you reach a certain scale, caching becomes basically a necessity. I mean, heck, even DNS is cached. The idea that caching is a failure of design is just wrong.
  - AtNightWeCode 4y ago
    Read again what I wrote from the beginning...

hinkley 4y ago

> Caching is for poor designs. Caching is the death of design. People who like to make decisions and then studiously avoid ever looking at the consequences of their actions don't seem to notice that once caching is introduced, the data model in the system either stops improving or begins to unravel. It becomes very difficult to benchmark the system looking for design issues because the real cost of a cold cache is very difficult to measure. And the usual argument that we can turn off the cache for performance analysis doesn't hold water for more than a few months. Pulling the same data twice, three times, ten times in a given transaction are all about the same cost, and it gets me out of trying to figure out how to plumb new data through the sequence diagrams. I can just snatch values out of global state wherever, whenever, and as often as I need them. Once people give up and start doing that, you can't turn off the caches anymore. When you started it cut the cost of the lookup in half, or a third. Now it's four, or five, or sixteen, and that call is now over-represented in the analysis, hiding other, more tractable problems. You've settled for your broken design, but also cut the legs out from under any of the tools that can dig you out of the hole you've dug. Caches are just global state under a different name, but slathered in RPC issues.

romange 4y ago

Some valid business use-cases allow eventual consistency. Think of social apps, for example. FB and TW have excellent engineering teams and they built huge systems that rely on caching layers. Similarly, with gaming companies.

dvt 4y ago
Once you reach a certain scale, caching becomes basically a necessity. I mean, heck, even DNS is cached. The idea that caching is a failure of design is just wrong.
- AtNightWeCode 4y ago
  Read again what I wrote from the beginning...