On 18/10/2019 12:10, Dweep Sharma wrote:
Yea, I had a look at readers, but it seems to fit this into my use
case, each client (browser) would need to process all the latest
messages to find the orderid of the user.
Do you recommend I continue with redis pub/sub where each
client/browser listens to messages for particular order only?
You haven't said anything so far about your use case, and this is the
first mention of "orders".
For order processing, the first thing that springs to my mind is
security. You don't want one client to be able to see or mess with the
order status of another client. Indeed, you don't want the client to be
able to mess with the status of their own orders, except in very limited
ways (e.g. they can submit a request for cancellation of the order or
change their delivery instructions)
Therefore I'd expect you'd want to build an order management system,
which the clients talk to via some sort of REST interface. It would do
its own authentication (user login) and is responsible for remembering
which orders belong to which clients.
You could then make your event-based order processing logic, but Pulsar
would be an internal component of this, not directly exposed to clients.
Trying to expose the queues directly to clients would be a highly
radical approach. I think you'd have to have one topic or namespace per
customer, so that each customer would be allowed to see only their own
orders. Plus it would have to be read-only, so customers can't mess
with their own orders. I suppose you could have a read-only topic for
"order updates" and a write topic for "order requests" (new orders
and/or requests to amend or cancel an order).
A better case would be to expose a way for clients to check for order
updates, which in turn talks to Pulsar behind the scenes. For example it
could use "Server-sent Events" (a.k.a. Eventsource), or something older
like COMET or long polling, to allow clients to wait for real time updates.
However, I'm making a whole bunch of assumptions here about what you
mean by an "order" here.
> Or can key_shared subscription mode pulsar help here
The subscription mode only matters when you have multiple consumers
sharing a single subscription on a topic.
This is for when you want a group of workers consuming messages from a
topic, but each message only gets delivered to a single worker. (i.e. a
worker pool).
The subscription mode controls how messages are routed to workers. It
only matters if you care about whether messages are processed in
sequence or not.
"key_shared" is a special case, which says that all messages with the
same key are routed to the same worker. Message key is an optional
property. For example: if you made the message key be the purchase
order ID, it would mean that all the messages relating to the same order
would be delivered to the same worker - and that therefore they would be
processed in the correct order by that worker.
HTH,
Brian.
