[berkes]

But the two main questions are:

Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? Boring doesn't have to be big-ball-of-mud, but the architectures you mention exist exactly to avoid big balls of mud from growing.

And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?

[porker]

> Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt?

So far there are zero clients and multiple pivots. The boring alternative needs only to yield higher velocity to be worthwhile, otherwise funding runs out before market fit and the current architecture achieves zero.

> And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?

Everything is stored in a popular RDBS. CQRS makes logging all data changes easier, but that is the only time intermediate states are used. If we did event sourcing I'd be keener on the architecture.