I often build TPC based "protocols" that are just newline delimited json in each direction, it's a nice middle ground between using an HTTP POST and something like gRPC.
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.
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 haven’t looked at the exact performance characteristics but it would be fun! You would have built in load balancing!
You can do a similar thing with Elixir and your own protocol (or the Redis protocol).
This pattern is very common in banking but require something like RabbitMQ or Azure service bus …
> 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.