The send put on hold
Tuesday May 19, ten twenty in the morning. I'm about to launch the second SMS wave of the re-enrollment campaign. Fifty-three former contacts from a ceramics workshop, a short link /r/<short_code> that sends each one to their personal funnel. Standard pre-flight: I grep the corresponding tokens to verify they're active. Fifty-two return what I expect. The fifty-third carries a non-null used_at, dated the same morning, because the test funnel I had gone through two hours earlier had consumed the token. If I launch the send, this contact receives a link that will answer 410 Gone. Catherine, testing the mobile version from the branch, writes me at the same moment to say she'd like me to check "the fifty-three anyway, because you know how it is". She's right. I don't send.
The rule that had served me for two months
Since late April, I've lived under a simple rule, stated in four lines in the project doctrine and that I hold as the most effective net I've laid down so far. Any stored value that resembles a duplication must be classified Live, Snapshot or Cache before being created, and each category imposes a different implementation. Live means don't store — read on the fly via a view. Snapshot means store and never recalculate — history is untouchable. Cache means store but declare the refresh mechanism in the same commit — named trigger, GENERATED ALWAYS AS, or materialised view. No cache survives without its explicit refresher; if you can't guarantee it, you fall back to Live.
