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.
Transactions should only fail, if the developer did something wrong. No system failures are allowed.
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

mindmap
	root((Transactions))	
		Clients
		s(("`Sharded State`"))
				Routing
					Caching
				Collections
				Rebalancing
				Schema Evolution
		Coroutines
			Dispatcher Service
			Transport Layer
				Authorization

There are two core components of union-db design: Sharded State and Transactions. One defines data, that can be stored inside the database, and another one defines operations, which can be performed on that data. To read more about these components follow one of these links:

Transactions

State & Rebalancing

But it may be hard to dive into these topics straight away, before understanding the lower-level primitives that are used under the hood. It is advised to first read the following documents in the order of listing:

Transactions section

Dispatcher Service & Coroutines

Transport layer

Authorization