Skip to content

PATTERN Cited by 2 sources

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

Last updated · 766 distilled / 2,225 read