This looks great! How were you planning on tackling distributed?
Each queue node can operate (mostly) independently, and this is good. As a consumer, I don't really care where my next message comes from, so I can minimize the amount of data that needs to have a "leader".
The only data that needs to be synced is the list of queues, which doesn't change often. If one server is full, it should be able to route a request to another server.
When we downscale, we can use S3/Dynamo (GCS/firestore) to store items and redistribute.
There's more nitty gritty here (what about FIFO queues? What about replication?) but the fact that the main actions, "enqueue" and "dequeue", don't require lots of coordination makes this easier to reason about comapred to a full RDBMS.
Or if you truly only need to store simple values in a distributed fashion, you could probably use etcd for that part.
[0]: https://rqlite.io/
Enqueue absolutely requires coordination, if not via leader then at least amongst multiple nodes, if you want to guarantee at least once delivery
If you don't guarantee that, cool, but you're not competing with sqs
disclaimer: I am one of the maintainers
It really depends on the semantics of the MQ you want to provide. There is rqlite if you want a distributed SQLite over Raft.
The question is what sort of guarantees you'd like to provide and how much of latency / performance you are willing to compromise