> Job payload & results are limited to 1 MiB each.
> Workq servers are standalone and do not speak to each other.
i.e. don't use it in production. This is a nice proof of concept, but let's not pretend that it is a professional grade product at the moment.
And nobody's ever going to trust your distributed capability if you implement RAFT yourself. You need to build upon something trusted or convince Aphyr to run Jepsen on your implementation. etcd is a common thing to build upon, and even it is only partially trusted.
I guess that could be said for a number of things that people successfully do?
Edit: for one great example of someone who didn't get discouraged by naysayers, check caddyserver.
And caddyserver isn't a distributed service, so the level of trust required is much lower.
Distributed services are difficult to get right for a wide variety of reasons, as shown by Aphyr's Jepsen tests.
Also I think the README of workq didn't mention anything about raft, which is fine, you can go very far without it.
My point is: encourage people to write code! Don't infect people with paralysis-by-analysis.
I spent 80% of time on Workq just writing tests for it and there is still so much to account for even as a standalone system.
On the bright side, projects like etcd & consul (I believe the author of Raft is helping out there) are getting better and better and can be embedded.
As they say, scaling is a nice problem to have.