> The "when" problem is dependent on your application architecture, not on your cache backend nor the number of keys in it. I would argue the "when" problem is

> The "when" problem is dependent on your application architecture, not on your cache backend nor the number of keys in it. I would argue the "when" problem is dependent on data models. And it's possible that we are referring to the same thing with different names. > If, overall, you have an extremely simplistic application architecture I mean FB is not a simple app. A complicated app can be built on a relatively simple data model as well (that's essentially how TAO works). But we do have memcache as well; and in some cases it can be complicated/hard. I can see that, and I won't argue against it. > Yes, #2, can't be avoided. But, while it is interesting, and - in some cases, given a specific caching stack - it may be relatively hard, it's not a general problem. I respectfully disagree. I explained in the blog post about why #2 is a generally hard problem. The analogy I like to use is Paxos. The protocol fits on a single slide. It's easier to feel like you have Paxos work; but it's very hard to have Paxos actually work.