Show HN: Go Command-streaming lib for distributed systems (3x faster than gRPC)
Why build around Commands? As serializable objects, they can be sent over the network and persisted. They also provide a clean way to model distributed transactions through composition, and naturally support features like Undo and Redo. These qualities make them a great fit for implementing consistency patterns like Saga in distributed systems.
On the performance side, sending a Command involves minimal overhead — only its type and data need to be transmitted. In benchmarks focused on raw throughput (measured using 1, 2, 4, 8, and 16 clients in a simple request/response scenario), cmd-stream/MUS (cmd-stream/Protobuf) is about 3x (2.8x) faster than gRPC/Protobuf, where MUS is a serialization format optimized for low byte usage. This kind of speedup can make a real difference in high-throughput systems or when you're trying to squeeze more out of limited resources.
By putting Commands at the transport layer, cmd-stream-go avoids the extra complexity of layering Command logic on top of generic RPC or REST.
The trade-offs: it’s currently Go-only and maintained by a single developer.
If you’re curious to explore more, you can check out the cmd-stream-go repository (https://github.com/cmd-stream/cmd-stream-go), see performance benchmarks (https://github.com/ymz-ncnk/go-client-server-benchmarks), or read the series of posts on Command Pattern and how it can be applied over the network (https://medium.com/p/f9e53442c85d).
I’d love to hear your thoughts — especially where you think this model could shine, any production concerns, similar patterns or tools you’ve seen in practice.
Feel free to reach me as ymz-ncnk on the Gophers Slack or follow https://x.com/cmdstream_lib for project updates.
It's ok that it runs faster, but much better if it's easier, safer, or more painless than the alternatives. The amount of code for a hello-world doesn't seem to indicate so, but maybe it pays off on more complex usecases.
Compression: cmd-stream-go doesn’t currently include built-in compression, but it’s a potential feature for future versions.
Retries & Latency: You're right, basic packet retries are handled by TCP. cmd-stream-go doesn't implement application-level retries directly, since those are typically left to business logic where factors like idempotency and error semantics come into play. Also, it uses the standard Go net.Conn without modifying TCP options like TCP_NODELAY.
go:generate for Commands: Good suggestion, this could be added in the future.