Time to live

Understand the concept

In plain English

Time to live, or TTL, is an automatic expiration setting for Azure Cosmos DB items. Instead of writing custom cleanup jobs for old records, you tell Cosmos DB how long items should remain after they are last modified. The setting is expressed in seconds. A container can have a default TTL, and individual items can override it when needed. Learners should think of TTL as a lifecycle tool for operational data, not as a backup or audit feature. Expired items disappear from reads and are removed in the background.

Why it matters

Time to live matters because stale data quietly becomes expensive, risky, and slow to query. Session records, device heartbeats, shopping carts, temporary recommendations, and security signals often have value for hours or days, not years. If teams keep everything forever, storage grows, indexes become heavier, queries scan more irrelevant data, and privacy reviews become harder. TTL gives developers a precise way to encode data freshness directly into Cosmos DB instead of relying on fragile scheduled jobs. It also forces an important governance conversation: which records are operationally temporary, which must be retained, and which must be exported before automatic deletion.

Technical context

In Azure architecture, TTL lives in the Cosmos DB data model and container configuration. It is applied by the database engine after a container-level setting enables expiration, with optional per-item values for exceptions. TTL interacts with partitioning, indexing, request units, backup expectations, change feed designs, and application data-retention rules. The control plane configures the container property, while the data plane stores item-level TTL values. Operators must understand that TTL deletion is automatic and asynchronous, and it should be designed together with compliance, analytics export, and recovery requirements.

Exam context

Compare with

Where it is used

Where you see it

1. In the Cosmos DB container settings, defaultTtl shows whether item expiration is disabled, inherited by default, or set to a specific seconds value. during data reviews.
2. In item JSON, a ttl property can override the container default for records that should expire earlier, later, or not at all. during retention testing.
3. In Azure CLI container output, resource.defaultTtl, partitionKey, and throughput details help operators review lifecycle behavior before changing production data. during cleanup validation. during operational review.

Common situations

• Expire shopping carts, sessions, device heartbeats, or temporary recommendations without running custom cleanup jobs.
• Keep high-volume operational containers small enough for predictable query cost and manageable storage growth.
• Apply item-level exceptions when most records should expire but a small subset needs longer retention.
• Separate short-lived operational data from compliance records that must be exported or retained elsewhere.
• Reduce privacy exposure by automatically removing data that no longer has a valid business purpose.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

Azure CLI is useful for TTL because the setting is easy to miss in the portal and dangerous to change casually. A senior Azure engineer wants repeatable commands that show the container defaultTtl, database, partition key, throughput, and account context before any update. CLI output can be reviewed in pull requests, run from release pipelines, and archived with change tickets. It also helps compare TTL settings across many containers so one forgotten development default does not reach production. For item-level overrides, CLI is adjacent rather than complete; SDKs usually handle item values, while CLI validates the container baseline. It also makes this review easier to repeat in pipelines.

az cosmosdb sql container show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --query "{defaultTtl:resource.defaultTtl,partitionKey:resource.partitionKey,provisioningState:provisioningState}" --output json

az cosmosdb sql container update --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --ttl <seconds>

az cosmosdb sql container list --account-name <account> --resource-group <resource-group> --database-name <database> --query "[].{name:name,defaultTtl:resource.defaultTtl}" --output table

az cosmosdb sql container throughput show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --output json

Architecture context

TTL is an architecture decision about data lifecycle, not just a database checkbox. It should be decided with product owners, privacy teams, analytics users, and incident responders because automatic deletion changes what future queries and investigations can see. I separate short-lived operational containers from record-of-truth containers whenever possible. For example, a device heartbeat container can use a short TTL, while billing events are retained elsewhere under a formal retention policy. TTL also influences throughput planning because background deletes use capacity after items expire. Good designs document default TTL, allowed item overrides, export paths, backup assumptions, and rollback limits. That separation keeps the design aligned with ownership boundaries.

Security

Security benefits come from reducing unnecessary data exposure, but TTL must not be mistaken for access control. Expiring old items can limit the amount of personal, behavioral, or security data available if an account is misused. However, anyone with read access can still read unexpired items, and anyone with write access may change item-level values if the application allows it. Protect Cosmos DB keys, prefer managed identity and RBAC where supported, restrict network access, and monitor container changes. Compliance teams should verify that TTL aligns with legal retention, because deleting required records too early can be as damaging as keeping sensitive data too long.

Cost

TTL can reduce cost by limiting storage, index size, backup footprint, and query work against stale data. The savings are strongest for high-volume temporary data such as telemetry summaries, carts, sessions, or short-lived recommendations. There is still an indirect cost: background deletion consumes request units, and too-short retention can create reprocessing, support, or compliance costs if teams need deleted data later. FinOps reviews should compare storage growth before and after TTL, watch RU consumption during expiration waves, and confirm that data is not being copied elsewhere forever. The cheapest TTL setting is not always the right business-retention setting. Review usage regularly so spend does not drift silently.

Reliability

Reliability impact is subtle because TTL deletion is asynchronous and depends on available capacity. Expired items stop appearing in reads, but physical removal may lag under heavy load or low request-unit availability. Applications should not rely on TTL as a millisecond timer or as a workflow trigger. If expired data drives downstream cleanup, use explicit events or scheduled processing instead. Reliable designs test how the application behaves when items vanish between reads, when item-level overrides are absent, and when background deletion competes with normal workload. Before changing TTL, teams should understand restore needs, backup mode, and whether deleted data can be reconstructed.

Performance

TTL improves performance indirectly by keeping containers smaller and indexes focused on current items. Queries that filter active records, dashboards that scan recent events, and point reads against hot data can benefit when old noise leaves the container. However, TTL is not a substitute for good partition keys, indexing policy, query design, or provisioned throughput. Background deletion can also create RU pressure if many items expire at the same time. Operators should watch query latency, RU charge, throttling, storage size, and expiration patterns after a TTL change. Staggered item timestamps and realistic retention windows help avoid large synchronized cleanup waves.

Operations

Operators manage TTL by inventorying Cosmos DB containers, reading defaultTtl values, checking item schemas for overrides, and confirming the owning team understands the retention behavior. During troubleshooting, they ask whether missing records were deleted by TTL, manually deleted, overwritten, or never written. During change review, they compare proposed TTL values with business retention, backup, analytics export, and alerting requirements. Operational dashboards should include storage growth, request-unit consumption, item counts where available, and application errors after expiration changes. Runbooks should explain how to disable or change TTL safely and what evidence proves that expiration is working as expected. Keep the runbook linked to owners, alerts, dashboards, and validation commands.

Common mistakes

• Setting TTL on a record-of-truth container and accidentally deleting data needed for billing, audit, or customer support.
• Expecting TTL to fire exactly at the expiration second or to trigger business workflow events by itself.
• Forgetting item-level ttl overrides, then assuming every item follows the same container default.
• Lowering TTL without confirming backups, analytics exports, and downstream reports no longer need older data.
• Ignoring RU pressure from large synchronized expiration waves after bulk imports or batch updates.