metadata_expire TTL versus dnf cache refresh for repository freshness

CentOS systems rely on dnf or yum to cache repository metadata, reusing it until the per-repository metadata_expire interval elapses. This design ensures minimal mirror traffic but can result in stale package views, where newly published packages remain invisible or dependency resolution operates against an older package set than the mirror actually serves. The effective time-to-live is governed by metadata_expire, defaulting to approximately 48 hours per repository, with no built-in push or invalidation mechanism to signal immediate updates. Adjusting metadata_expire lower in /etc/dnf/dnf.conf or individual repo files reduces staleness at the cost of increased mirror bandwidth consumption per dnf invocation. Alternatively, running dnf clean metadata followed by dnf makecache forces an immediate refresh for the current session, but this discards all cached metadata and re-downloads it, which may be impractical for automated or bandwidth-constrained environments. The trade-off between accepting up-to-48-hour staleness for efficiency and paying repeated mirror downloads for freshness remains unresolved, particularly across CentOS 7 (yum) and CentOS 8/Stream where cache paths and default TTL values differ. These considerations give rise to three questions: What metadata_expire interval balances package currency and mirror overhead for typical CentOS Stream workloads? How does the lack of a repository push mechanism affect long-term cache management decisions? What are the operational trade-offs of substituting dnf --refresh for full cache wipes in automated update schedules?