Files
ObsidianJournal/Work/Training/Advanced Distributed Systems/Advanced Distributed Systems Design - Module 12 - Long Running Processes.md

1 line
1.1 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
What is a process? A set of activities in sequence triggered by internal and external triggers.  Long-running processes are multi-trigger processes.  They have state to keep. The fact that it's a "long-running process" does not mean it has to take 5 minutes or an hours or five days.  The issue is more the multi-trigger effect and the need for keeping state between the two triggers.  We don't know when the second trigger (or any subsequent) will come. The early work for long-running processes was done in the 80s and 90s for long-lived transactions.  The answer to solving this issue was to break up the transaction into several small, short-lived transactions. The best, most reliable way to resolve race conditions is through retries. Orchestration is not a service by itself. Unit testing sagas is important. Sagas don't have to end!  When a saga is not "running" it's just sitting in the database.  So what?! A saga that "runs forever" is just a record in the database.  Moore's Law is in our favor in the case of storage--it's increasing by leaps and bounds and getting cheaper all the time.