We have a consumer portal where
We have a consumer portal where conversations (messages) are generated. We need these same conversation messages to be delivered in real time to a different portal. The requirements are:
Messages must be delivered in FIFO (first in, first out) order.
No message should be dropped.
Messages should be routed per conversation (e.g., if there are 50 different conversations, each message should go only to its corresponding conversation thread).
The system should scale and maintain ordering per conversation.
Can this be implemented using Cloudflare (Queues, Durable Objects, or both)? If so, what’s the best approach?
4 Replies
Need more concrete requirements.
1. Concrete number of messages per second? Number of threads/conversations? Messages per second per conversation?
2. Does this have to be "guaranteed at least once" delivery or something else? Can the target system handle duplicates sent, and does the system have idempotency in place already?
3. What is the target system? An HTTP API call? Does it support batch calls or is it one call per conversation? one call per message? other?
4. Size of each message? Only text or images/blobs as well?
Having the answers to Lambros' questions would help. In their absence....
Ordering could be accomplished without a complex coordination mechanism by using a monotonic ULID if you can accept rare moments where the message stream has a gap that's filled in a short while later. This says nothing about delivery guarantees though.
Cloudflare Queues have some guarantees about delivery and ordering, but the consumer is a Worker so that says nothing about the last mile to your "different portal".
HTTP streams and WebSocket connections both guarantee in-order delivery, as long as you are careful about your in-app processing.
The most connection-agnostic in-order mechanism follow the Actor programming model which involves outboxes and inboxes where the next message is not sent until the prior one is acknowledged. DO's have an input queue but it's not durable so you still have to implement your own durable (saved to storage) outbox and inbox. The Actors base class may have some (all?) of this. I remember Brayden, the Actors base class author, mentioning input queues but I don't know if they are durable.
It probably doesn't apply in your situation because it sounds like your "different portal" might be outside of Cloudflare, but... In the special Cloudflare RPC case of extending from RpcTarget, and just reasoning from implementation details I know, I'm pretty sure it will always be in-order for a given stub/session (even if Cloudflare doesn't guarantee it). I think it's less likely, but not impossible, for regular Cloudflare RPC/Service bindings to also be in-order.
Hope this helps.
10 messages per seconds, 10 conversions as of now
Yes, delivery only once. Yes the consumer/different portal platform sends unique webhook events.
One call per message
Only text message is included. A small json object having 50-100 text fields.
You can use the webhook response to detect whether or not the message was delivered. I recommend an inbox on the other end of that so you can maintain in-order processing inside of the external system but that could be overkill if it's really simple.
The rest of what I wrote still holds.