Scalability

Reboot is vertically and horizontally scalable: your durable state data types are transparently partitioned by id across the CPU cores of a Reboot cluster.

Because of Reboot's method safety hierarchy and support for distributed transactions you might not even notice that you are writing a distributed application.

In practice, Reboot's architecture means that you can increase the number of clients that your application serves by adding cores, while keeping latency effectively constant.

Replicated State Machines

If it's helpful, you can think of your durable state data types and the operations on them as replicated state machines.

In general, state machines receive inputs and return outputs while maintaining internal state, and replicated state machines are state machines whose state has been replicated for fault-tolerance.

Why replicated state machines?

Replicated state machines offer high levels of concurrency in a distributed system.

Small, discrete pieces of information with flexible yet well-defined boundaries allow for state to be stored and retrieved more efficiently than in a traditional database. State can be relocated between machines at many different levels of granularity as an application scales.

You, as the developer, can define the boundaries between state to match the level of granularity that best suits your application.

Distributed transactions

Reboot implements distributed transactions using two-phase-commit atop RocksDB's battle-tested storage engine.

Transaction methods transparently execute as distributed transactions if they involve multiple partitions.