We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Caching Strategies
Time To Live: how long a cached entry, DNS record, or packet is valid before it expires and must be refreshed or discarded.
In short
TTL (Time To Live) is a value that says how long a piece of data stays valid before it must be discarded or refreshed. It shows up on cache entries, DNS records, and network packets, and once the clock runs out the data is treated as stale and is either deleted, re-fetched, or dropped.
In short
TTL (Time To Live) is a value that says how long a piece of data stays valid before it must be discarded or refreshed. It shows up on cache entries, DNS records, and network packets, and once the clock runs out the data is treated as stale and is either deleted, re-fetched, or dropped.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers TTL across a run of lessons, not one page. These 4 alone are about 100 minutes of step-by-step reading, every one with a quiz.
How to choose a cache TTL from your own traffic. A sweep of seven TTL values on skewed traffic shows the hit rate ceiling and the cost of staleness.
A refresh-ahead cache reloads hot entries before their TTL ends, so readers stop waiting. A Redis lab measures the factor, the cost and stale-while-revalidate.
Messages that self-destruct, setting time limits on message relevance.
Find the constraint limiting system performance, profiling, tracing, and load testing.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Time To Live (TTL)pay once,
yours for life
TTL stands for Time To Live. It is a number attached to a piece of data that answers one question: how much longer is this allowed to exist or be trusted? When the timer hits zero, the system stops treating the data as fresh.
The same idea shows up in three very different places. On a cache entry it means how long you can serve the cached copy before you have to go back to the source. On a DNS record it means how long a resolver may remember an IP address before asking the authoritative server again. On an IP packet it is a hop counter that drops by one at every router so a lost packet cannot loop forever.
What matters is that TTL is a promise about freshness, not a guarantee about correctness. A 300 second TTL on a cache says the data could be up to 300 seconds out of date. You are trading a window of staleness for fewer reads against the slow, authoritative source.
In a cache like Redis or Memcached, you set TTL when you write a key, for example SET session:abc value EX 3600 stores it for 3600 seconds. Each key gets an expiry timestamp. Redis uses lazy expiration plus a background sampler: a key is removed when you try to read it after expiry, and a periodic job also samples random keys to clean them up so memory does not fill with dead entries.
In DNS the TTL is part of the record itself and travels with the answer. If example.com returns an A record with a TTL of 3600, every resolver and operating system along the path may cache that IP for one hour. Lowering the TTL to 60 before a planned IP change makes the switch propagate in about a minute instead of an hour, which is why teams drop DNS TTL ahead of a migration.
In an IP packet the field is different. IPv4 calls it TTL and IPv6 calls it Hop Limit. It starts at a value like 64 and every router that forwards the packet subtracts one. When it reaches zero the router drops the packet and sends back an ICMP Time Exceeded message. The traceroute tool exploits this by sending packets with TTL 1, 2, 3 and reading the error from each hop to map the route.
Pick a short TTL when data changes often and stale answers hurt, like inventory counts or live prices. Pick a long TTL when data rarely changes and you want to spare the origin, like a product description or a logo image. A TTL of zero or none means cache forever, which is fine for immutable content with a version in the URL.
The core trade-off is freshness against load. Short TTLs keep data accurate but push more traffic at the backend on every expiry, and a thundering herd can hit when many entries expire at once. Long TTLs cut backend load and latency but let users see old data for longer, and they make invalidation slower because you cannot un-cache something that is already on a remote resolver or browser.
A common pattern is to combine TTL with explicit invalidation. Set a generous TTL as a safety net, then actively purge or update the entry when you know the source changed. Many teams also add a small random jitter to TTLs so a batch of keys does not all expire on the same second.
Say you run a news site behind a CDN. The home page changes every few minutes, so you set a Cache-Control max-age of 120 seconds. The CDN serves the cached page to thousands of readers and only hits your origin server once every two minutes per edge location, which is the entire reason the site survives a traffic spike.
Article images never change once published, so you give them a max-age of 31536000 (one year) and put a content hash in the filename. A reader downloads each image once and the browser reuses it for a year with no further requests.
When you publish breaking news you do not want to wait two minutes, so you send a purge request to the CDN for the home page. That removes the cached copy immediately, the next request rebuilds it from origin, and the TTL countdown starts fresh. TTL handles the steady state and manual invalidation handles the urgent case.
Redis
Per-key expiry via EX, PX, or EXPIRE; lazy plus sampled background eviction removes keys once their TTL passes.
Cloudflare
Edge caches honor origin Cache-Control TTLs and expose Edge Cache TTL rules, with one-click purge for early invalidation.
AWS DynamoDB
A TTL attribute on an item lets DynamoDB auto-delete expired rows in the background at no extra cost, common for sessions and events.
AWS Route 53
DNS records carry a TTL that controls how long resolvers cache the answer; operators lower it before IP or failover changes.
The data is treated as stale. A cache entry gets deleted or re-fetched from the source, a DNS resolver asks the authoritative server again, and an IP packet is dropped by the router that decremented it to zero.
It depends on how often the record changes. A stable record can use 3600 seconds (one hour) or more to reduce lookups. Before a planned IP change, drop it to 60 to 300 seconds so the change propagates quickly, then raise it again afterward.
Usually yes, because more requests are served from cache and the origin sees less load. The cost is that users may see data that is out of date for longer, and invalidating something already cached far away becomes slower.
The concept of an expiry is the same, but the mechanism differs. In caching and DNS it is a time duration in seconds. In an IP packet it is a hop counter that each router decrements by one, not a clock.
Set it at write time with SET key value EX 3600 for 3600 seconds, or add it later with EXPIRE key 3600. Use PERSIST to remove the expiry and keep the key forever, and TTL key to check the remaining time.
Refresh-Ahead Cache: How It Works, Measured on Redis
A refresh-ahead cache reloads hot entries before their TTL ends, so readers stop waiting. A Redis lab measures the factor, the cost and stale-while-revalidate.
Feast Hands-On: The Same Join, Row for Row, Until a Row Has No Snapshot in Its Window
Does a real feature store do the point-in-time join we wrote by hand? I gave Feast 0.66.0 the same customer tables as lessons 1 and 2 and asked for all 86,045 training, validation and test rows of this chapter. With no time limit, Feast's file store equalled lesson 2's merge_asof on 86,045 of 86,045 rows, to the last bit, and lesson 1's model trained on it scored the same test AP, 0.5450. A row stamped exactly at the cutoff was taken every time. Then I set a 90-day TTL, a limit on how old a value may be. The file store did not return those rows empty: 41,232 of them were missing from the output, and the dropped rows bought at 9.8 percent against 31.7 percent for the rest. A check added after review found the cause is wider: with no TTL at all, 5,942 of 5,942 rows dated before a customer's first snapshot were also missing, contrary to Feast's own docs example. The SQLite online store ignored the same TTL and still answered for 3,082 of those customers. An unknown customer came back as None, with no error.
Message Expiration
Messages that self-destruct, setting time limits on message relevance
Caching Predictions: Every Real Hit Was Stale, and Dropping Old Entries Did Not Help
Can you cache a model's answers, and what does a stale cached answer cost? I replayed the 7,403 real invoices of lesson 1 and five sets of simulated page views through caches keyed three ways, with time-to-live values of 1 hour to 30 days. On real invoices every hit was stale by construction, because an invoice is exactly what changes the inputs, and still no time to live could be told apart from online scoring. On simulated page views a 1-hour cache keyed by customer hit 66.8% of requests and changed 0.4% of the scores it served. A key made from the model's own bins never served a wrong score and hit 66.4%. Dropping entries when a new invoice arrived did not help: at 30 days it was below online in 4 of 5 draws, keeping in none, and compared directly it was below keeping in 2 of 5.
Bottleneck Identification
Find the constraint limiting system performance, profiling, tracing, and load testing
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
DNS
The phonebook of the internet. Translates human-readable domain names (google.com) into IP addresses that computers understand.
Cache Stampede
When many requests hit the database simultaneously because a popular cache entry expired. Solved with locking, probabilistic early expiration, or request coalescing.
Cache Eviction
The process of removing entries from a cache when it's full. Common policies: LRU (least recently used), LFU (least frequently used), FIFO (first in, first out).
Cache-Aside
A caching pattern where the application checks the cache first; on a miss, it fetches from the database and populates the cache. Also called lazy loading.
This page explains the idea. The "Time To Live (TTL)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Time To Live (TTL) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about TTL in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
