Scalability features

[smartin015]

Another aspect of #2 is that the size of the queue and of the printer cluster will grow substantially - rather than tens of printers, there may be hundreds or thousands (or more!) and similarly so with jobs / queue items.

Lots of peers

• New peers that join should not overwhelm RAFT consensus - handled via pubsub
• Adding a new peer should not noticeably increase background network bandwidth (i.e. no constant status reports; only when queried) - handled via pubsub / leadership-only polling
• When a peer goes dormant for too long (minutes?), it should be removed from RAFT and reassigned (assuming it's a member of the consensus group). Any held locks should time out if not renewed. avoided with discrete list of electable peers

Lots of jobs (queue items)

• When the queue is large, it should automatically shard into multiple pieces. Those pieces are then handled by printers that are auto-assigned the shards based on a hash of their ID.

Lots of queues

• When there are hundreds of thousands of queues, the results will not fit nicely into a single DNS entry, nor even potentially a single IPFS entry. The registries should allow indirect references to other registries.
• There should be some way of estimating peers connected to a queue - done probabilistically
• There should be a way to estimate how many queue items there are
  • Note: not done yet as sharding must be implemented first

Lots of users/permissions

• Adding another user should not bloat the core data structure - done because no central user registry
• Users should retain minted tokens that delegate control, signed by some authority. These tokens will have a TTL and must be renewed.