the main reason for using client generated ID’s is that a client can send multiple commands for the same aggregate, without the need to wait for a return value of the first command. I don’t think mysql key generator will have any trouble keeping up.
The disruptor commandbus solution solves another problem. I have seen cases where applications would have so many concurrent (and active) connections, that there was high contention. In such a case, using fewer connections in a smart way could help. The disruptor command bus can do exactly that.
The link you sent is interesting, to say the least. I don’t think the UUID has anything to do with it. It is probably purely the use of a unique index. It seems that MySQL has difficulty managing large numbers of unique indexes. With a auto increment, mysql knows it doesn’t need to check anything. There can’t be any value equal to the generated one.
In the JPA Event Store, the unique key is the combination of the aggregate identifier and the event’s sequence number. Using an auto-increment key in mysql is not really going to be a solution. But it may be interesting to find out if there is a way to remove the need for a unique index…
To be continued…