PATTERN Cited by 1 source

TTL-based resource lifecycle

A resource management pattern where every provisioned environment receives a default time-to-live (TTL) with extension options, automatic expiration notifications, and cleanup — preventing resource sprawl without requiring manual decommissioning.

Structure

1. Default TTL assignment at provisioning time (e.g., 90 days for builder environments)
2. Notification chain — approaching-expiry alerts at configured intervals (Slack, email, etc.)
3. Extension mechanism — owner can extend before expiry without reprovisioning
4. Automatic teardown — expired resources are reclaimed without human intervention
5. Configurable per resource type — different TTLs for different environment classes

Forces

• Self-service platforms produce resource sprawl if cleanup is manual
• Engineers forget about environments they provisioned weeks ago
• Platform limits (catalog instances, concurrent workloads) become ceilings without reclamation
• Hard-delete without warning destroys work-in-progress

Consequences

• Cost controlled automatically — abandoned resources can't accumulate indefinitely
• Platform limits stay within bounds via continuous reclamation
• Engineers maintain awareness of their resources via notification transparency
• Extension mechanism prevents premature loss of active environments

Known Uses

• systems/databricks-fevm — 90-day default TTL, Slack notifications at provisioning / approaching-expiry / deletion, configurable per resource type

Seen In

• sources/2026-07-23-databricks-self-serve-infrastructure-vending-machine — "Builder environments live for 90 days by default, with extension options available, while other resource types have configurable TTL"