DNS TTL Strategy
Choosing record lifetimes to balance failover speed against query volume, knowing that resolvers and clients do not reliably honour them.
DNS is frequently proposed as a failover mechanism, and it is a poor one for reasons worth understanding before depending on it.
A short TTL is meant to allow fast redirection. In practice the observed switchover is much slower than the TTL, because intermediate resolvers sometimes enforce their own minimums, some ignore TTLs altogether, and many application runtimes cache DNS results for the process lifetime regardless of TTL — the JVM's historical default of caching indefinitely being the classic example that has caused a great many prolonged incidents.
So DNS failover should be treated as eventual and partial: most traffic moves within a few multiples of the TTL, and a residual fraction continues hitting the old address for a long time. Any plan that requires the old endpoint to stop receiving traffic at a specific moment is unsound.
The practical strategy: keep TTLs short (30 to 60 seconds) on records you may need to move, longer on stable records to reduce lookup latency and cost, and lower them well in advance of a planned migration — since lowering a TTL only takes effect after the previous, longer TTL has expired everywhere, which is the step people forget the day before a cutover.
For genuinely fast failover, use anycast, a load balancer with health checks, or client-side awareness of multiple endpoints. Use DNS for the migrations and coarse routing it is good at.