Streaming Best Practices

Note:

You must connect to the WebSocket at least once every 24 hours. If not, then you must send the optional "offset" input parameter together with the value of the last offset you received.

Ensure there is a minimum of 10000ms (10 seconds) between sending the "complete" message to close one WebSocket connection and the next "subscribe" message to reopen a WebSocket connection.

The Streaming API is not throttled. As events are produced, they are immediately sent out. Potentially, this means many events will be pushed at the same time and create a backpressure.

To cope with this potential backpressure, it is essential the consuming architecture can scale, for example, by buffering before writing to back-end systems. If the backpressure exceeds the ability of the consuming architecture to scale, you can disconnect the WebSocket and then restart it later once more capacity is available in the consuming architecture. Any events that occurred since the WebSocket disconnect will be sent as soon as you reconnect.

While no option is currently available to clear the backlog of events, the "latest" parameter allows you to skip to the latest Business Event in the stream and continue processing from there.

To ensure streaming clients are resilient, redundancy in clients is key. However, only one client can be connected to consume events from a single chain on a single application key. The best practice is to create multiple consuming clients, but maintain a log of which client is connected. The consuming clients not connected should not send requests to the streaming gateway (as these will receive a 4409 response), but wait until the first connected client disconnects before the next client connects. Some partner solutions on the marketplace already implement this pattern.

For more information on best practices for the streaming API, refer to the Streaming APIs topic.