I am writing an application where any change in the salesforce sobject will be directly synced in my db.I used streaming API concept.I wanted to know whether this streaming api is reliable and wont give me any problem in sync as this data affects my DB.

2 Answers 2


Yes, the Streaming API is reliable and durable. Not only does it deliver messages within a very tight window after the insert/update completes, it also has a recovery mechanism that allows you to replay any messages sent in the last 24 hours. This means that even in the event of your application server restarting or network connectivity problems, you'll not miss any events.

However, you may also choose to use the SOAP API Replication calls, but you'll have to deal with waiting up to five minutes to synchronize your data instead of nearly instantly. The replication calls can be used for a greater window of time, however, up to 30 days, meaning that you don't need to synchronize as frequently. Also, unlike the Streaming API, it is not based on a query and can retrieve any records modified in the provided time frame, not just those meeting a certain criteria. This may be more appropriate for your use case.


In my opinion is only quite reliable. I've been implementing streaming API for my company's project and here are pitfalls I trapped into:

  1. When your org is heavily used by DML operations some notifications are dropped. In other words you will see a gap in replayId (i.e.: 1, 2, 4) and if you want to receive that missing notification you will have to unsubscribe and resubscribe again to replay it. Unfortunately this usually takes around 1.5-2.5sec. Moreover current EMPConnector version doesn't support that.
  2. You have to remember that replayIds are not guaranted to be consistent. In other words a gap in replayId can also mean that everything is fine and there is no any dropped event (most probably some rolled back transaction).
  3. From time to time (especially on sandbox instances), you will receive error message with advice reconnect=none (see below Bayeux message) which will cause your connector to disconnect permanently. Again, this scenario is not covered by neither CometD nor EMPConnector and you have to detected it and reconnect on your own.

    {clientId=abcd, advice={reconnect=none, interval=0}, channel=/meta/connect, id=11005, error=403::Unknown client, successful=false}

  4. There are some differencies in line ending format, streaming API sends it differently than they are retrieved by SOAP API.

  5. When connector will be required to re-handshake (which may be caused by timeout, bug, whatever) it will also have to resubscribe to all previous subscribtions which is supported by EMPConnector and works fine unless timeout encounter during subscription. If that happen, connector won't retry subscribtion and you will be not receiving events from one or more PushTopics.

That's all. Cheers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .