A storage library does not choose a cluster leader

You have implemented rows, pages, indexes, logging, and recovery. Instead of maintaining all of that local storage machinery yourself, you could adopt an existing storage library. But replacing local storage does not automatically solve the distributed problems from the preceding lessons.

RocksDB and Cassandra are useful examples because they supply different scopes of functionality. RocksDB is an embedded key/value storage engine; the host program calls it within its own process. Cassandra is a distributed database with its own data placement, replication, and request coordination.

Start three independent local stores

Suppose we put an HTTP endpoint around a RocksDB instance and start that program on servers A, B, and C. A request writes stock/27 = 9 to A. Assume A uses a configuration and storage system that make the acknowledged local write durable.

What tells B and C about it? In this design, nothing yet.

Server A
Local key stock/27 = 9
The request reached this process.
Server B
Local key stock/27 = 10
No replication protocol was added.
Server C
Local key stock/27 = 10
A third copy is not an agreement.

Each engine can manage its local files correctly while the service as a whole returns conflicting values.

The host still needs routing, replication, failure handling, and an explicit consistency promise. If A disappears, the service cannot simply infer that B’s value includes every acknowledged update. Those are the replication and leadership obligations we already derived.

Recognize what the larger system supplies

Cassandra includes a distributed placement and replication model. Its architecture uses partitioning to assign replicas and supports tunable consistency for requests. Ordinary updates and specialized conditional operations have different semantics; choosing the product does not eliminate the need to specify the operation’s guarantee.

Both systems use log-structured storage ideas, but Cassandra is not merely “RocksDB plus networking.” Similar local techniques do not imply identical interfaces, transaction behavior, or failure handling.

Inside an LSM engine, compaction reconciles local sorted files and discards entries that are safe to remove. Across Cassandra replicas, repair addresses divergent copies. These are different jobs. A locally compacted file can still contain a value that another replica has not received.

Predict the proposed fix

An engineer adds a second local disk to A and calls the three-server service highly available. Which part of the earlier failure has that change resolved?

Separate disk redundancy from service authority

It may improve survival of a specified local disk failure, depending on the storage arrangement. It has not propagated the accepted update to B or C, established a safe next owner, or defined what clients should read after A becomes unreachable. The service still needs those protocols.

Sources: RocksDB’s scope and storage design, Cassandra’s distributed architecture, and Cassandra repair.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter