Guidelines For Safe Use And Concurrency

There are few rules regarding what you’re allowed to do with cascaide for safe use.

When Spawning Nodes

You may spawn multiple nodes concurrently if they belong to separate cascades. You can achieve good parallelism with cascades.

If you want to spawn multiple nodes in parallel belonging to the same cascade, ensuring order of state updates is on you. You may do it by ensuring one writes after the other, by waiting on some condition before writing. Or another pattern you can use is fan out fan in. Essentially, you write design the parallel nodes not to write updates at all, but conditionally spawn a consolidation node basis whether the other node has completed or not. Then let the consolidation node make the writes.

Regarding UI Nodes

You may spawn as many as need in parallel from server or client, as long as they are ephemeral nodes that only observes or initiates cascades (no persistence, no state updates)

If they are part of a cascade, persisted, and require state updates the same rule as above apply when spawning in parallel.

Delegation and Recursion Behaviour in Serverless Environments

Using these patterns in serverless is risky as of v0.5.0. It will break graceful timeout handling as it assumes only one node and one cascade is active within a single request scoped store. You may make multiple requests with many cascades running in parallel, so thats a good way to get around this for serverless (the pattern shown in hotel booking agent tutorial)

You may use them without issues in a server without timeout limits.

Recursion gets tricky beyond certain depths, so for production, stick to a max depth of 2 or 3. These depths cover most use cases and at each depth you can have many parallel agents. If you run a system at depth of 2, and each depth you create 5 parallel agents that can recurse deeper, the math is:

root : 1 agent depth 1 : 5 agents depth 2: 5x5 = 25 agents

You get a total of 31 agents. Of these at a single time, 25 at most might be streaming results back to your UI.

At depth 3, now you possibly have 5x5x5 = 125 AGENTS.

Thats a total of 156 agents. You will start to to see the SSE connection strain. Both depth and number of parallel agents per depth matter.

A good strategy is to

1. limit depth
2. limit number of parallel agents at each depth
3. switch streaming off for agents at depth (check out conventions section to see how)