In a scaled backend infrastructure (imagine game engine) which subscribes to bunch of ably channels and processes messages (say user input update in a game), is there a recommended pattern to ensure a message is processed at most once? If there are multiple instances running i'd imagine the event will be received from all instances and potentially be processed multiple times
if there are no inherent solutions within Ably, i'd imagine i have to introduce my own scalable message queue layer (Kafka or some sort) that will ensure write-only-once, or add a ably integration layer (aws lambda, firehose), but this would introduce some more latency if there are tons of data we need to process. Imagine a multiplayer game with numerous scaled up game servers.
At first sight, it appears that you need Ably Queues. Classic Ably Pub/Sub channels are perfect for fan-out. If there is 'work' that needs to be distributed between your servers for each published message, then it is better to use Queues.
You can provision one or more queues for your app, however by default each new app is provisioned without any queues. You can easily do this in your Ably Dashboard. Once a queue is configured, you will need to set up a queue rule that enables messages to be republished from pub/sub channels into a physical queue.
Please, also take a look at https://ably.com/blog/message-queues-the-right-way