You're under the mistaken impression that we have the same data/log architecture as described in the Calvin paper, which requires that every host talk with every other host. That is not true of FaunaDB.
If not, we’re now in an unfortunate situation where neither your practical nor theoretical capabilities are public knowledge.
> every host talk with every other host
Only every shard
> you seem to think you know more about FaunaDB's architecture than you do
You are perhaps being uncharitable. The only public statements I am aware of about Fauna's capabilities relate to its Calvin heritage. I have only been asking if my understanding is correct regarding both Calvin and its application to Fauna. However, none of the prior issues you responded to were problems with the original Calvin paper either, at least by my reading.
> for scalability, this insertion process happens in batches, and the log itself is replicated and partitioned
This is the link's total exposition on this topic, but it is consistent with my reading of the Calvin paper.
If any log partition becomes unavailable, the log in its entirety becomes unavailable until that partition recovers[1].
Anyway, it feels like we’ve wasted enough of each others’ time without making much progress. Might as well leave it there.
[1] ... and every log partition must communicate with every replica, hence NxN (or MxN)
The salient aspect of the paper is how it derives the log logically, not how that is mechanically implemented in a real system outside of academia.
> However, none of the prior issues you responded to were problems with the original Calvin paper either, at least by my reading.
I wasn't clear what exactly you do (or don't) know of the architecture which would lead you to believe this NxN messaging story, as that relates directly to your contention regarding the scalability (or not) of the architecture. That much is clear to me now.