Thanks very much for thinking about adding this little caveat - part of the reason I'm keen is that this really is a good list of 'things to think about' re cac

Thanks very much for thinking about adding this little caveat - part of the reason I'm keen is that this really is a good list of 'things to think about' re caching, and I'd like to add this one to the pile. With the TTL advice, why do you think this would make it _more_ baffling for the user? If the choices are 'it's wrong "forever"' or 'it's wrong for 5 minutes', isn't the latter the better one? I'd have to have a compelling reason to cache indefinitely if I knew it might be wrong... admittedly, if there are a lot of writes (where we're most likely to mess the cache up) you're likely to get a new cached value quickly. In terms of whether this issue is cache specific, I honestly think it is _in this context_ because of the way you've phrased the article: that you can add an external cache to your db accesses and everything is faster without any cost in correctness. It's almost better to think of it as 'I'm adding an entirely new kind of database', and realise that keeping those databases reliably in sync is non-trivial without relaxing your guarantees.