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.