The short answer
Expiration removes data after a time limit. Eviction removes data to manage memory pressure. A key can be evicted before its TTL would have expired.
If your application assumes a cached key will exist until its TTL ends, that assumption is too strong.
Give a value a lifetime
In a disposable Redis environment:
SET demo:weather "sunny" EX 60
TTL demo:weather
GET demo:weather
Immediately after the SET, TTL should report a value at or below 60 seconds. After expiration, GET returns a missing-value response. The exact formatting depends on your client.
Decide what happens when memory fills
An eviction policy chooses which keys may be removed when the configured memory limit is reached. Some policies consider all keys; others consider only keys with expiration. A no-eviction policy rejects applicable writes instead of choosing victims.
Inspect the engine's current documentation and deployed configuration. Managed services may expose configuration differently.
Separate cache data from essential state
If the same instance contains disposable cache entries and data you cannot afford to lose, an eviction decision can become a correctness problem.
Use separate instances or a design that clearly separates those guarantees. Persistence and replication are different topics again; neither makes an arbitrary cached value permanently available.
A quick design check
For every key family, answer: may it disappear early, how is it rebuilt, how stale may it become, and what should the application do if rebuilding fails?
Those answers are more useful than choosing a TTL by habit.