What LinkShift caches for 5 minutes, and why
I built LinkShift to help people avoid breaking links during migration. One thing that matters a lot in a redirect system is cache behavior. In the codebase, there are three useful layers to think about: redirect con
I built LinkShift to help people avoid breaking links during migration.
One thing that matters a lot in a redirect system is cache behavior.
In the codebase, there are three useful layers to think about:
- redirect context, keyed by hostname
- link map context, keyed by map ID
- edge hostname routing
Under normal operation, a successful write invalidates the relevant cache right away.
If invalidation fails, live traffic can stay stale for up to 5 minutes.
There is also a short negative cache for missing or deleted link map IDs, around 60 seconds.
That matters because a deleted map referenced by a rule should fail closed and move on to the next rule, not keep hammering the database.
The practical lesson is simple: if your product rewrites traffic, document the worst-case stale window honestly.
βUsually immediateβ is fine. βUp to 5 minutes if invalidation failsβ is better.
I added a short note in the docs about this because it comes up whenever people test migrations, redirects, or edge behavior.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.