Ryan Barrett

I also wonder if this might be the root cause of https://github.com/snarfed/bridgy-fed/issues/1595

^ _Narrator: it wasn't._

Doing this should stop us from skipping sequence numbers sometimes and needing to wait for them in the firehose server, which should largely get rid of the delays we see...

I tried switching our [datastore concurrency mode](https://cloud.google.com/datastore/docs/concepts/transactions#concurrency_modes) from PESSIMISTIC (ie locking) to OPTIMISTIC (optimistic concurrency/MVCC) just now. We see a fair amount of contention on ATProto repo and sequence number...

Unfortunately adding sequence number allocation into the commit transaction brought back the contention, with a vengeance, as expected. Commits were failing at roughly .5qps, and that's _after_ 10 retries. Pessimistic...

I'm reconsidering the premise here. We emit 1-2qps of ATProto events right now, and growing. Almost all are commits, which are relatively heavy datastore transactions. Do we really need to...

I'm going to call it here. Allocating sequence numbers transactionally with commits causes too much contention. Commits are too heavy and long-running. I think the 5m buffer for reordering is...

From https://github.com/snarfed/arroba/issues/52#issuecomment-2816324912 : > if you can send a #sync at account creation time, when the repo is empty, that is helpful. same time as a first #commit is sent;...

We're now emitting this, just not at quite the right time. Our firehose event order for new repos is #commit, #account, #identity, #sync, but the commit should actually be at...

This is in `Repo.create`. Next step here is to pull sequence number allocation out of `Storage.commit` so that we can change our order of operations to first allocate the sequence...