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

1 line
1.1 KiB
Markdown
Raw 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.