Earlier quoted context omitted.
>Pick a a stable, guaranteed-to-exist, shard key (composite or atomic properties) and use that. This is a pretty risky approach since it's almost certainly the case that you won't end up evenly distributing your data across shards using this method.
more recent customers/users/accounts probably do more actions than very old accounts though, how is that not also eventually creating uneven shards?
For example, consider a system which monitors farm equipment for Caterpillar and John Deere. Lets say each company has 100k devices which send one message per day to the system.
While it is easy to envision sharding device messages based on "DeviceId / Company" in this hypothetical system, there would be no value sharding the two customers.