I did not give up and made things even more complicated: CRDTs. It wasn't what I needed. At some point, I discovered Operation-Based CRDTs. Synchronizing the operations log instead of the full app state looks simple. I elaborated this idea further and decided to use it for the synchronization

Then, I tried to store the hash of every object in the database and compare these hashes to determine the state diff. At some point, I went even further and tried to apply Merkle trees (en.wikipedia.org/wiki/Merkle_...) 🤪. Everything looked overcomplicated.

I spent around half of the year trying different approaches. It was hard to choose a suitable sync algorithm. I had never implemented such features and had been overthinking it for months. First, I read the rsync algorithm (rsync.samba.org/tech_report/...) documentation and tried to apply it.

Moreover, the overall design underwent significant changes during implementation. For example, I replaced the custom auth with Cloudflare Zero Trust Access.
The next steps are debugging, fixing bugs, and writing some documentation.
I hope I will finish it in a month or two 😊

Significant achievement 🎉

I'm sure you are really a cool CTO 🤘😎

how big is your future? (hegdenu.net/posts/how-bi...) – The author in this blog post dives a bit deeper into task size: why it is important, workarounds, and tracing instrumentation. Recommend reading.

How to prevent it? Fortunately, clippy has a lint that can catch huge futures: rust-lang.github.io/rust-clippy/...
`#![warn(clippy::large_futures)]`

As you know, every async piece of code is transformed into a struct that implements the Future trait. And future context becomes these struct fields. Of course, I'm not the first one who has faced this issue: users.rust-lang.org/t/stack-over...