Temporal consistency guarantees tradeoffs

Hi Temporal team!

My team has deployed a Temporal cluster and has implemented several workflows on top of it recently. Several of those workflows fall into the category of promotional notifications. Temporal’s programming model looks like a perfect fit for them, but there is a concern that Temporal is not as cost-efficient for these scenarios as some other lower-level approaches. One reason for that is the strong guarantees that Temporal provides. Our use cases don’t necessarily require 100% durability: we obviously don’t want workflows to get into an inconsistent state, but it might be ok to lose e.g. 0,1% of signals or activity invocations. Due to that, solutions like “queue something through Redis and live with the fact that it might get lost” are acceptable and cheaper in terms of the underlying infrastructure.

I know that right now there’s probably nothing we can do about that - we either get on board with both Temporal’s programming model and its strong guarantees or none of them. However, I wonder if you have some plans or ideas for other options sometime in the future, where we could have some Temporal’s workflow-as-code model with trade-offs in terms of some of its durability? Do you think Temporal is a good fit for use-cases like these?

We don’t have concrete plans to provide non 100% reliable options.

At the same time, Redis backend storage for Temporal should be technically possible. Maybe one day it will be added/contributed to the Temporal.

2 Likes