Teleport auth server role cache TTL causing stale authorization after role update

Teleport auth server caches role mappings for users and services to reduce load on backend storage such as DynamoDB or etcd. The cache is populated on first lookup and refreshed only after a configurable TTL, reported as 5 minutes by default in Teleport v13.

Role changes made by an administrator are not reflected in authorization decisions until the cached entry expires or the auth server is reloaded. No automatic cache invalidation occurs on role update events.

This creates an unresolved trade-off between immediate consistency for access revocation and backend load and performance. The goal is to clarify the documented caching behavior and its impact on authorization timing.

What is the propagation window for role additions and removals under the default auth_cache_ttl? Is cache invalidation on role updates part of the design, or is TTL-based expiry the intended behavior? How does the TTL interact with new authorization checks versus existing authenticated sessions?