4 ms·
Fair dos - I will try to add it when I get some time later today. The email thing is just an example, you might have a preference on how to handle that particu
by calpaterson 6y ago
Fair dos - I will try to add it when I get some time later today.
The email thing is just an example, you might have a preference on how to handle that particular case but hopefully you can recognise the principle I'm getting at.
I don't necessarily agree that this problem is a cache specific issue and I definitely wouldn't start putting random TTLs on things in an attempt to try to hack around it. If anything, that is likely only to make the issue even more baffling for the user if it does occur. And of course you are now back to TTL numberism - how long a TTL should you set? If it really is a realistic concern (and I would suggest it's not for most!) then time to look at having locks somewhere.
- wryun 6y agoThanks 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.