data in EU is never unnecessarily routed through the US

You lose the benefits of a global resilient realtime platform that routes data efficiently i.e.

If your servers are unable to cope with a sudden burst of realtime data then the lat/long data is lost.

Any latency in your own servers will affect your clients.

I’ve seen other realtime platforms mostly recommend approaching this problem in one of three ways:Īll data that would have been broadcast in real time is instead sent as an HTTP request to your own servers.

Trigger actions as part of your workflow when a vehicle reaches its destination or when it’s delayed.

For example, you may want to store the most recent lat/long every 15 seconds.

Persist roll up data for the vehicle’s GPS locations into your backend database.

When pub/sub feels like forcing a square peg into a round holeĮxpanding on the example above, if you were to build a complete vehicle tracking system, you may have additional requirements to:

Any number of devices can subscribe to updates on the channel dedicated to the vehicle, and those devices will see the position of the vehicle in real time.

As the publishing client receives an acknowledgement (ACK), then it can trust that the data has been broadcasted successfully.

The vehicle publishing its location is decoupled from anyone subscribing to messages.

The pub/sub pattern and Ably's platform is a good fit because: If you set out to build a similar GPS delivery tracking system, the flow of data between the vehicles and consumers wishing to track parcels may look something like this: Take a company like Urbantz that rely on Ably to broadcast the position of vehicles as they traverse our roads. A typical scenario where the pub/sub pattern works well Queue based patterns on the other hand typically require that each message is received only once by a single subscriber in a linear yet distributed fashion, often to be processed by workers. This pattern is used by most realtime messaging providers, including Ably.

Finally, I look at the solution to this problem.Ī pub/sub pattern is designed so that each message published is received by any number of subscribers. In this article I explore the juxtaposition of a pub/sub fan-out messaging pattern and a queue based pattern, and why both are sometimes needed. You can also read our recent post on SQS FIFO Queues, which looks at why converting a distributed system to FIFO and exactly-once message processing requires considerable user effort and what to bear in mind if planning to implement this.

Message queue