undefined | Better HN

0 pointse12e6y ago0 comments

Hm. So there is some magic to avoid all roc calls and pub/subs going through dapr?

Eg: if I have a thousand users subscribed to a channel - only setup would involve dapr, and the rest would be dependent on my pub/sub queue manager (eg: plain redis, or rabbitmq) keeping up?

But from the [ed: dapr api microservice component] consumer viewpoint it's just "ask dapr for subscription", "ask dapper to broadcast a message" - and you're off to the races?

0 comments

yaronsc6y ago

Having the calls go through Dapr is actually a pretty powerful feature: Dapr will handle retries and handle failures and guarantee an at-least-once delivery. For high-throughput scenarios we have a gRPC client which can see a much higher throughput than regular HTTP.

Yes, you are right: from the consumer's viewpoint, it's "ask to subscribe, ask to publish a message" and you're off.

e12eOP6y ago

So it would be fair to say that dapr scales to "fairly big" throughput - but not the right tool if your goal is in the ballpark of saturating a 10gps network with messages?

(mind, I have no such ambissions presently, just trying to get my head around what dapr is - and is not)

SideburnsOfDoom6y ago

> but not the right tool if your goal is in the ballpark of saturating a 10gps network with messages

If that's in any danger of happening, then you scale out not scale up. e.g. run 100 worker instances to process the messages. each one gets 0.1 gps of messages.

Microservices are good at scaling out as needed. I mean, not completely painless, but better than the alternatives.

1 more reply

zubairq6y ago

So dapr reminds me of Istio here

j / k navigate · click thread line to collapse