I like to think about it in terms of what the code for managing a shopping looks like.
Without Temporal, you store the state of the cart in the DB, load it when the app interacts with your backend, run some business logic and serialize state back into the DB.
With Temporal, first of all, there's no DB. The entire flow is modeled in a single piece of code.
Your Workflow can listen to user signals to update the cart, queries to get the cart state, schedule durable timers to remind a user that their cart is abandoned after days and months.
Wouldn't you still want to actually store transactional data inside of a database? Like, you would use all the workflow stuff to do all the business logic, and the workflow(s) themselves are long-running workers which interact with the database(s).
I'd imagine if anything it makes databases _easier_ to reason with, because you could shard by workflow steps or something.
By “there’s no DB”, burgundy means that the dev doesn’t interact with the DB—the state of all their code is automatically being saved to the DB at each step.
If there is no DB how will company go about collecting metrics?, in your example what would the process to query on number of abandoned carts or after how long or after adding which product did they abandon the cart?
temporal supports elasticsearch for arbitrary querying across workflows, or you can instrument your workflows with logging to an analytics db of your choice
Instead of directly using queues in a Temporal Workflow, the Workflow (which is written with plain code), schedules an Activity that the system is responsible for, behind the scenes, the Activity is just an item put on a queue.
Activities have retry policies which are also handled by the system.
If an Activity attempt fails and should not retry according to the policy, an exception is thrown in the Workflow to be handled using code.
https://github.com/temporalio/sdk-python
Disclaimer: I work for Temporal