#Best practices

#Queuing Events

To maintain performance with a high volume of subscriptions, the event platform requires a response within the specified time limit, please refer to this page to know more. Handle received events using a queue or asynchronously to ensure you acknowledge the event quickly, before processing it.

#Handling 429 Responses

The platform can send many events in a short time, potentially causing overload and leading to 500 responses from your side. In such cases, your subscription may be suspended. By implementing a proper 429 response mechanism, you can delay event processing to maintain service stability and avoid suspension.

#Suspending and Resuming Subscriptions

If you are unable to guarantee a positive response when events are sent (e.g. during infrastructure maintenance) you may decide to suspend/resume your subscription to avoid it being suspended in accordance with our suspend/revocation policies. During the suspension period, events in the pipeline and new events generated by the PIM can't be recovered. You'll be able to receive new events as soon as you resume the subscription.

#Ignoring Duplicate Events

In some cases, such as response delays, you might receive the same event multiple times. To identify and handle these duplicate events, you can rely on the id of the event. This allows you to process each event only once and maintain data integrity.

#Implement Reconciliation Processes

Your app shouldn't rely solely on receiving data from the Akeneo Event Platform. Because you may not receive events if you suspend your subscription or your server is not able to handle them over the maximum retry, you should implement reconciliation jobs to periodically fetch data from the PIM.

You could do this in the background or offer reconciliation and syncing options to the user. For example, your app's UI could contain a button that triggers a manual reconciliation process by calling the relevant API endpoint and fetching the requested data.