Expiration date
An expiration setting specifies when, or after what duration, an item, data, resource, or right ceases to be valid, available, or retained.
API Design Patterns
An expiration time is the point in time after which a resource is intended to be deleted or otherwise no longer retained.
- How it is used
- Controls how long operations, soft-deleted resources, page tokens, and cached responses remain available.
- How deep it goes
- Defines field behavior, policy choices, cleanup conditions, and timing recommendations, but stops short of implementation algorithms.
- Examples
- Uses 30-day Operation and soft-deletion windows, short-lived page tokens, and a five-minute sliding request-cache window.
- What you can do after
- Operate/configure it by assigning explicit expiration fields and choosing consistent, documented retention policies.
Learn Go with Pocket-Sized Projects
A time to live is a duration after which stored data is considered expired and should no longer be used.
- How it is used
- Controls when a cache stops serving stored values that may have become outdated.
- How deep it goes
- Defines TTL storage, construction, updates, reads, deletion, cleanup, and a timing-based test.
- Examples
- Uses a generic Go cache, timestamped entries, time.Duration values, and a 100-millisecond test.
- What you can do after
- Build it from scratch by adding configurable expiration and expired-entry cleanup to a generic cache.
Read how Learn Go with Pocket-Sized Projects explains expiration date →
Authorization in Action
An expiration date is the recorded date after which a document or credential is no longer considered valid for its intended purpose.
- How it is used
- Uses expiration dates to bound credential validity within authorization decisions and complement issuer-based revocation checks.
- How deep it goes
- Defines fixed validity periods and explains their limits, stopping short of specifying expiration-date formats or implementation protocols.
- Examples
- Uses one-year employment credentials, certification renewal cycles, and revoked employment credentials as concrete cases.
- What you can do after
- Evaluate/understand when a credential’s fixed validity period is insufficient and when revocation or freshness checks are also required.
Latency
Time-to-live is a caching mechanism that limits how long an entry remains valid before it is treated as expired and removed or refreshed.
- How it is used
- Controls cached-data freshness when backing-store updates may occur without the cache knowing.
- How deep it goes
- Explains TTL definition, units, trade-offs, DNS choices, and expiration checks, but does not specify a cache product implementation.
- Examples
- Uses DNS mappings, stable IP addresses, dynamic load-balancing records, and database-backed cache entries.
- What you can do after
- Operate/configure TTL by selecting a freshness interval and implementing expiration checks before serving cached data.
Related concepts
- cachingconfigures · Caching is the practice of storing reusable data or computation results so later access can avoid repeating retrieval or computation.
- st.cache_dataconfigures · st.cache_data is a Streamlit decorator that caches data-returning function results and reuses them across reruns when inputs are unchanged.
- cache invalidationaddresses · Cache invalidation is the process of making cached data ineligible for reuse, typically by marking it stale, removing it, or refreshing it when its source or validity conditions change.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.