>> “Why 480 shards? … 480 is divisible by a lot of numbers”.
This is an important point, doing things divisible by 12 gives you a lot of flexibility. It’s not a coincidence both time (clocks) and degrees (360) are multiples of 12.
Numberphile made a video about "highly composite numbers" / "anti-primes", which are numbers that have more factors than all smaller numbers. https://youtu.be/2JM2oImb9Qg
There is an oeis sequence of them that starts "1, 2, 4, 6, 12, 24, 36, 48, 60, 120, 180, 240, 360, 720, 840...", which notably does not include 480. https://oeis.org/A002182
"anti-prime" is just Brady trying to rebrand an old boring name to sound cooler (as he does). "highly composite" has a perfectly well defined meaning already, trying to shift it to shoehorn in some artificial distinction between it and "anti-prime" is counterproductive. If the aim is to produce a more descriptive name for a similar sequence of numbers that includes 480, I think GP's "weakly highly composite" is much better. I might propose just "weakly composite" or "mediocrely composite".
Edit: Actually, this was (also) already done by Ramanujan and has a better name than any proposed here: http://oeis.org/A067128 - "largely composite numbers" which does in fact contain 480. Perhaps every sharded system should choose a shard count from this list?
Thanks for correcting me, but I don't think drawing a distinction between "anti-prime" (clearly specific) and "highly composite" (vague) is counterproductive. On the other hand, "highly" and "largely" mean roughly the same thing, so treating "highly composite" and "largely composite" as distinct in this way is linguistically counterintuitive and counterproductive. Likewise, "weakly highly" reads like ambiguous nonsense when you don't go out of your way to specially define it.
It's true that 480 isn't on the list, but you'll notice there is a big skip in the list between 360 and 720, so if you want something in between, 480 is a good choice since it's still a multiple of 12.
Yeah, to be clear, I think there are many important factors that go into choosing a shard count, and blindly jumping to something just because it's some platonic mathematical ideal seems naive. I just thought this is a neat related fact and is probably a good starting point if you're in the process of choosing a shard count.
This is the kind of engineering that it's almost impossible to screen in interviews (particular for HR-minded pals) and is a big part of what makes a 10x-100x engineer (which definitely DO exist).
Obviously not this thing just by itself, but this sort of knowledge, applied to everyday decisions that get compound over time.
My rule of thumb is one factor of three and then as many factors of two as you need. Adding five is not much different from two twos or a two and a three. Ditto for seven.
The only downside imo is not having ten(s) be a balanced deploy number.
This is an important point, doing things divisible by 12 gives you a lot of flexibility. It’s not a coincidence both time (clocks) and degrees (360) are multiples of 12.