A saved business's link is always computed from the business's currently-active domain, never read from the domain id we stored when it was saved — because that stored id goes stale and poisons the link.
When a user saves a business, the obvious schema records which domain they saved it on (lb_follows.domain_id) so we can link back to it later. Reading that stored id at render time feels correct and is one join cheaper. It is also a bug, and a quiet one.
A business's domain is not stable. Sites move between roots, subdomains get regenerated, a business gets a better home, a domain is deactivated. The moment any of that happens, every lb_follows row that captured the old domain_id now points at a domain that may be inactive, wrong, or gone. The user's "saved" link 404s or lands on a dead host, and nothing errored when it broke, so nobody notices until a person taps a saved item and hits a wall (a dead end, the one thing we refuse to ship).
Always derive a saved business's URL from that business's currently-active domain, resolved fresh at render time, never from the domain_id stored on the follow. The stored id is treated as poisoned. The join is one step longer and the link is always live.
The insight is recognizing that a foreign key can capture a fact that was true once rather than a fact that stays true, and that "the domain this was saved on" is the second kind. The stored value looks authoritative and is actually a snapshot with an expiry you cannot see. This is the same shape as fix the source, not the symptom: do not patch dead saved-links after the fact, compute the link from the source of truth every time so it cannot go stale.