Pexip Engage uses a distributed architecture to provide a performant, scalable and resilient platform on which customers can rely. This means that the system processes requests across multiple servers, and data updates may not be immediately consistent across all servers. Rather than strong (immediate) consistency, the API guarantees eventual consistency.

Eventual consistency is a model where all updates to data will eventually be consistent, but it may take some time for all servers to have the updated data. This is because data updates are made asynchronously across the distributed system, and different servers may have different versions of the data at different times.

When using the API, developers should take into account that data consistency may not be immediate across all servers. Developers should design their applications to tolerate this eventual consistency, by avoiding assumptions about the data's state or using strategies such as retries when necessary.

Taking the Create subjects endpoint and Update subject scheduling settings endpoint as an example for provisioning a subject with some corresponding scheduling settings.

The two endpoints mentioned must be called for this purpose:

1. Create a subject using the Create subjects endpoint endpoint.

   A POST /subjects request with request body

   {
     "translations": {
       "name": [
         {
           "language": "en",
           "value": "My subject"
         }
       ]
     },
     "subjectGroupId": "123",
   }
   

   which returns

   {
     "id": "456"
   }
   

2. Patch the scheduling settings using the Update subject scheduling settings endpoint endpoint.

   A PUT /subjects/456/scheduling-settings request with request body

   [
     {
       "meetingType": "OFFICE"
     },
     {
       "meetingType": "PHONE"
     }
   ]
   

It cannot be assumed that the server processing the second API call immediately knows about the newly created subject from the first API call. Such an assumption could cause the second API call to unexpectedly fail due to an unhandled error.

To adequately deal with this situation, a retry mechanism could be implemented. Such a mechanism can then respond to an error resulting from the second API call by waiting a while before trying again. If the error persists, you can respond by waiting a little longer before trying again. This can be repeated until a certain limit is reached and an error is thrown. See also exponential backoff.