Hacker News Reader

Comment by dljsjr | Hacker News Reader

I’m not 100% sure I’m understanding but if the idea is to implement a “traditional”/synchronous RPC mechanism you can do that using the PubSub functionality trivially and I’m not sure which additional moving parts it adds unless you’re in a situation where you have to cluster Redis (which has a reputation for being a PITA but isn’t that hard honestly).

The only use case that really jumps out is when you don’t want a broker because you don’t want a single point of failure but now you’re embedding a Redis server implementation in every one of the services in your mesh and I’m not convinced that’s much better but I can see where it might be helpful.

View on HN

> I’m not sure which additional moving parts it adds

> The only use case that really jumps out is when you don’t want a broker

The broker is exactly the additional moving part I was referring to.

Pubsub over a broker is more complicated than RPC operationally, whether you're already using the broker software elsewhere or not.

Especially when you're looking at the RPC server living inside an erlang VM that's already really good at handling things like load shedding of direct connections.

I don't think this is anything to do with Redis server, you are simply using the Redis wire protocol/parser? I could be wrong...

Correct this post is about the Redis Protocol.

That’s correct but my point was that Redis has an out-of-the-box solution for “message passing arbitrary data using the Redis protocol over TCP to named endpoints”, and Redis Server is a very lightweight piece of software. Even if you aren’t using it as an in-memory key-value DB it’s not a big problem to pull it in to your stack even if you’re only gonna use it for PubSub or RPC/IPC.

This is a super cool write-up and I’m not saying anything negative about what the author did. I like it a lot. I’m just asking from a technical and curiosity perspective what the advantages are to this over using the stuff Redis Server already provides which can do the same thing.

I suppose the main advantages would be less dependencies (no Redis server). Less overhead (you aren’t routing though anything)

I haven’t looked at the exact performance characteristics but it would be fun! You would have built in load balancing!

With Elixir specifically, you have the option of clustering these things. We (fly.io) send messages between servers using NATS. This works well with geographically distributed infrastructure, messages are somewhat peer to peer. If we were using Redis, we'd need a round trip to a centralized server. And we'd need the internet to always work well.

You can do a similar thing with Elixir and your own protocol (or the Redis protocol).

Problem with redis as a Pub-sub is it’s not transactional. So a consumer can’t take temporary lease on a message try to process it and then delete the message if it was processed successfully.

This pattern is very common in banking but require something like RabbitMQ or Azure service bus …

Reply on news.ycombinator.com