5 ms·

"A little clickbaity" if you are generous. Short-sighted and grandiloquent if you are not. Short-sighted because it narrows the original problem (cache invalid

"A little clickbaity" if you are generous. Short-sighted and grandiloquent if you are not. Short-sighted because it narrows the original problem (cache invalidation) to a specific version (detecting cache invalidation errors past an arbitrary time-frame). Grandiloquent because it then claims to have "solved" the general problem, whereas they haven't even solved the narrowed version. Notice their own premise: > For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all. This is a practical attitude that can yield great results, and probably even good engineering practice. However, it will never lead to solving a problem, because a problem isn't solved until you prove that it is.

uvdn7 4y ago
> For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all. Thanks for the comment! I stand by this claim; I would love to hear more about why an anomaly (any anomaly) matters if it can't possibly be observed by any client for stateful service.
- tofuahdude 4y ago
  It is just the difference between "matters" and "solved".
- kilburn 4y ago
  The claim itself is fine because it is kind of tautological. An error that cannot be observed in any way is probably not an error. However, you have to prove that it can't be observed. This is quite different than what the described system does though. The system flags errors that have been observed. The correct claim to go with what the article does would thus be: > For any anomaly in a stateful service, it is an anomaly only if the current clients running their current operations happen to observe it. Otherwise, we argue that it doesn't matter at all. It's much more noticeable this way, isn't it?
  - uvdn7 4y ago
    This is a fair point! The exact same argument applies to normal exceptions and errors. It might be the case that out of quadrillions of queries a day, just none of them hit the error path, and hence we won't observe any issues. I can see that in this case, if it matters or not becomes somewhat subjective. It's a good point though!

uvdn7 4y ago

> For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all. Thanks for the comment! I stand by this claim; I would love to hear more about why an anomaly (any anomaly) matters if it can't possibly be observed by any client for stateful service.

tofuahdude 4y ago
It is just the difference between "matters" and "solved".
kilburn 4y ago
The claim itself is fine because it is kind of tautological. An error that cannot be observed in any way is probably not an error. However, you have to prove that it can't be observed. This is quite different than what the described system does though. The system flags errors that have been observed. The correct claim to go with what the article does would thus be: > For any anomaly in a stateful service, it is an anomaly only if the current clients running their current operations happen to observe it. Otherwise, we argue that it doesn't matter at all. It's much more noticeable this way, isn't it?
- uvdn7 4y ago
  This is a fair point! The exact same argument applies to normal exceptions and errors. It might be the case that out of quadrillions of queries a day, just none of them hit the error path, and hence we won't observe any issues. I can see that in this case, if it matters or not becomes somewhat subjective. It's a good point though!