<aside> 💬 This document is open for commenting.

</aside>

Long-term vision

It is easier, cheaper and safer to develop and maintain infinitely scaling high-performance dapps with union-db, than without it.

Goals

• The database should have an ability to scale indefinitely, across an unknown number of canisters.
• Scaling has to be performed automatically and gradually, meaning that no extra computation, storage or cost should be introduced without being immediately utilized.
• Performance, overal system resilience and data availability should, if possible, benefit from scaling - not suffer from it. This implies that the database shouldn’t have any single point of failure - if a single shard is under heavy load, all the others should continue to work properly.
• There are three main focuses of the implementation: correctness, developer experience and performance, listed in the order of their priority.

<aside> ⚠️ Despite performance being only the third in the list, it is important, even for the first implementation, to provide a powerful improvement basis for the future work.

</aside>

System components

All components of union-db are modular and can be used without the others.

1. Database state section describes the data structure used in the database, addressing and information related to horizontal scaling.
2. Queries section describes by example how one can fetch a lot of data from such a database, using regular canister query methods and a little bit of client-side code.
3. Transactions section describes by example a general purpose distributed transaction engine based on Saga pattern.
4. Authorization section briefly describes how to protect a multi-canister application against other clients, which may try to intervene into an internal protocol.

Read these sections in the order they are presented here, for best experience:

Database state

Queries

Transactions