
The Possible Studio leverages stateless APIs across the board, which is great from an integration perspective. Clients never need to know the state of the story being worked on, or the specifics of what they need to generate \- they just make requests like “generate *voiceover*”, “create *shot*” or “play *movie*”. However real-time collaboration also means that clients can make story updates over each other that need to be reconciled before the API response is received, otherwise we run the risk of clients seeing stale responses.

Here is a simple example flow:

1. Client 1 write a *shot*, then chooses to animate the *shot* using Luma Dream Machine (in the *shot* camera panel) \- this sends the API request to “animate *shot*”  
2. Client 2 also opens the *shot* camera panel which triggers the same API request to “animate *shot*” (since the APIs are stateless)  
3. Client 1 receives the API response, which is stale because a new Luma image-to-video was requested by client 2  
4. Client 2 receives the API response, which is not in sync with client 1 because it has the new Luma image-to-video that was requested

![](/blog/media/realtime-collaboration-1.png)

To prevent these issues, each of our APIs leverages the same “job system” module called ARTISAN \- a custom package we wrote to manage response consistency during real-time collaboration. ARTISAN manages API states via firestore transactions \- this method allows us to use it as a module instead of having to deploy it as a “job system” service, which would increase response latency.  

![](/blog/media/realtime-collaboration-2.png)

There are 2 types of artisans (or workers):  
**Render artisans**
* Used in APIs that manage story renders such as *voiceovers*, *shots* and *movies*  
* Handles reconciling response consistency by checking for already running identical APIs

**Gen artisans** (we’ll cover this next week)
* Used in APIs that make calls to 3rd party providers such as Luma Dream Machine image-to-video gen or Eleven Labs text-to-speech gen  
* Handles queuing jobs to the same 3rd party provider so we don’t exceed each provider’s concurrency limits

Now we use a **render artisan** in our example flow:
1. Client 1 write a *shot*, then chooses to animate the *shot* using Luma Dream Machine (in the *shot* camera panel) \- this sends the API request to “animate *shot*”  
2. Client 1’s API uses its **render artisan** to check if this API is already running (which it isn’t), so it kicks off the 3rd party provider request  
3. Client 2 also opens the same *shot* camera panel which triggers the same API request to “animate *shot*” (since the APIs are stateless)  
4. Client 2’s API uses its **render artisan** to check if this API is already running (which it is), so it just waits quietly  
5. Client 1 receives the API response, which is correct since its the only API that sent the 3rd party provider request  
6. Client 2’s API is notified that the API it was waiting for is done via firestore document notifications  
7. Client 2’s API now retrieves the same response information and returns  
8. Client 2 receives the API response, which is in sync with client 1 since it was retrieved from the same response notification

![](/blog/media/realtime-collaboration-3.png)

Artisans leverage unique keys to manage & reconcile jobs, so an important step is making sure we pick the right story states to generate these keys.  Since the APIs are stateless, a **render artisan** key should only contain the minimal set of parameters that make this API call unique \- which are usually the parameters passed to the API.
