Horizontal Scaling

A TypeDB cluster replicates every change with the Raft consensus algorithm. Every server holds a complete copy of all the data, so any server can take over the work of any other. A change is committed only once a majority of the servers have durably written it to their replication logs. This guarantees that a committed transaction is never lost, even if the server that accepted it fails right afterwards, and that every server applies the changes in the same order.

A TypeDB cluster operates with a single primary and several secondaries. The primary processes all client operations: schema and data writes, reads, database and user management, export and import. Centralizing them on one server keeps consistency simple and applies every change in a strict order. The secondaries receive the committed changes from the primary and apply them to their own copies, staying in sync and ready to take over.

Write throughput is determined by the capacity of the primary and is scaled by increasing its resources (see vertical scaling). In the current version, read transactions are served by the primary as well; the secondaries do not serve client transactions.

If the primary fails, the remaining servers elect a new primary from among the secondaries within seconds, and the cluster continues to accept transactions. Transactions that were open on the failed primary are closed and have to be retried. A cluster of 2N + 1 servers tolerates the failure of N servers at once; a three-server cluster keeps running with one server down.

Interacting with a cluster is very similar to interacting with a single server. The driver can be given the address of one server or of several; it discovers the other servers from the cluster, finds the current primary, and routes transactions to it. When the primary changes, the driver finds the new one and retries, so your application code for opening and running transactions is the same whether you are connecting to a single server or a cluster. See Drivers in clustered TypeDB for the details.

TypeDB’s replication model provides strong consistency. A transaction is acknowledged to the client only after a majority of the servers have durably stored it, so a committed transaction survives the loss of any minority of servers. Every transaction, including a read-only one, observes all the transactions committed before it, on whichever server was the primary at the time.