Shaping the Future of Collaborative Applications Shaping the Future of Collaborative Applications

Do you notice lag when collaborating online with colleagues around the world? You’re not alone! As the future of work moves increasingly remote and users and colleagues spread out worldwide, apps and database systems are being challenged to support collaboration in real-time with low latency across continents and oceans.

To address these challenges, James Arthur and Valter Balegas founded Vaxine, a low-latency, geo-distributed database that allows developers to build collaborative applications using  CRDTs: conflict-free replicated data types. Receiving a pre-seed investment from Lunar Ventures earlier this year, Vaxine is about to turn cutting-edge research into applications. 

Learn more about Vaxine from our interview with the CEO, James Arthur:

Why Did You Found Vaxine?

I was looking into the global write-path latency problem you encounter when building a geo-distributed application: How do you keep data consistent without waiting on the speed of light?

You can see from platforms like Cloudflare and that there’s a trend to serving applications close to the user. Network latency often dominates response times, so moving your app or functions close to the user can radically increase the snappiness of your app. 

However, once you move your app close to the user, you also need to move your data. Otherwise, the gains in latency between the app and the user are undermined by the increase in latency between your app and the database. As it turns out, that’s a really fiendish problem due to some “minor” constraints like the CAP Theorem and the speed of light.

I started investigating the problem by making a low-latency global database using existing technology, YugabyteDB, to be specific. This worked, but when talking to developers about it, they all focused on the consistency guarantees and the trade-offs YugabyteDB was making to achieve low latency. 

It led me to dive into the scientific literature on consistency modes for low-latency databases: and I discovered a tremendously rich vein of research by academics, including Marc ShapiroNuno Pregucia, and Annette Bieniusa with concepts like highly available transactions, conflict-free replicated data types, and causal consistency, which had all been combined in the development of the open-source project Antidote DB.

Collaborating with the academics and my co-founder Valter, we started to design a database system built on top of Antidote DB that could demonstrate its viability for real-world applications. The result is Vaxine: a low-latency, rich-CRDT database that can work as a standard backend for collaborative, geo-distributed applications. 

How Does Your Database Work? 

Current generation global databases such as Google Spanner and CockroachDB use network communication to coordinate when writing data. Because this network communication goes all across the world, it runs up against the speed of light. It can easily take a whole second for the system to agree on a write that could otherwise be made in less than 1 ms.

Vaxine eliminates this network communication, speeding up writes by several orders of magnitude using CRDTs: A data structure that can be updated independently and concurrently without the need for additional requests to ensure consensus between replicas. It’s always mathematically possible to resolve inconsistencies, ensuring strong eventual consistency.

Why Is It Called Vaxine?

Initially, the project started as Electric DB with a strong focus on low latency. However, over time it turned out that low latency combined with data integrity and immunity from consistency issues is a lot stronger differentiator, and Vaxine captures this proposition better than Electric.

There’s also a strong naming convention in the research literature based on the concept of a “cure” for consistency issues. So AntidoteDB implements the Cure protocol, and Vaxine is a delivery mechanism for the Antidote. 

We’re also developing Vaxine using the programming language Elixir. An x in the name is very common in that ecosystem because Elixir files use the `.ex` file extension.

How Did You Evaluate Your Startup Idea?

I talked to potential users early on and got valuable feedback. This led me to focus not only on low latency but also on data integrity and consistency – and research different data consistency setups. 

Special thanks go to Purva Gujar, who has been there from the start. She has helped tremendously with the customer development process, not least through her extensive contacts in the San Francisco developer scene. Also to Paul Harter, who was instrumental in the earliest days when the project was forming, and, of course, to my co-founder Valter, who pioneered rich-CRDTs in the first place.  

We’ve also had a lot of interest and encouragement from the Erlang and Elixir community, which is very friendly and welcoming. There is a lot of value in focusing on a tight-knit community first before going wider – just like Heroku started as a platform for Ruby applications.