Reduce timeout traffic by adding TTL-based saga expiration #985
Description
Describe the feature.
Is your feature related to a problem? Please describe.
In environments with large numbers of sagas that become idle, the only current way to ensure those sagas are eventually cleaned up is to schedule a saga timeout and complete the saga when that timeout fires.
This works, but it generates avoidable overhead: a timeout message is dispatched, travels through the broker, is received by the endpoint, loads the saga, and then completes it immediately.
For sagas that require no business action on timeout and only need automatic expiry, this results in unnecessary broker, network, and storage IO.
Describe the requested feature
Add native TTL (Time To Live) support to saga persistence implementations that can leverage the underlying storage engine's automatic expiration capabilities.
With TTL, the persister would write an expiration timestamp to the saga record, allowing the database to remove the saga instance automatically after the defined period, without sending a timeout message or invoking a saga handler.
This removes message traffic, reduces load on the endpoint, and avoids redundant storage operations for sagas that only need passive expiration.
Describe alternatives you've considered
The current workaround is to set a saga timeout when the saga is created and mark it as complete in the timeout handler.
While functional, this generates a message for every saga instance and causes the endpoint to process a handler invocation that contains no business logic.
The workaround is effective but costly in high-volume or idle-heavy scenarios.
Additional Context
Implementations such as DynamoDB already support native TTL cleanup at the storage level. Leveraging these capabilities would significantly reduce infrastructure load in systems that rely heavily on passive saga expiration.