High-level Design for Better Availability and Scalability

Let’s see Megastore’s high-level design before discussing how Megastore improves availability and scalability.

High-level design

The components involved in the high-level design of our system are as follows:

• Application server: It is used to deploy Megastore along with the Megastore library. There is a defined local replica on each application server. By sending transactions directly to the local Bigtable, the Megastore library makes Paxos operations on that replica persistent.
• Megastore library: Applications connect to the Megastore library, which implements Paxos and other algorithms, like picking a replica for reading, catching up with a replica that is falling behind, and so on.
• Replication server: Periodically, replication servers look for unfinished writes and provide Paxos no-opno-op means no operation. It is a machine language command that does nothing. (Source: Wikipedia) values to finish them.
• Coordinator: A coordinator server keeps track of a set of entity groups for which its replica has seen every Paxos write.
• Bigtable: For scalable fault-tolerant storage within a particular data center, we utilize Google’s Bigtable, which allows us to handle arbitrary read and write throughput by distributing operations across several rows.

The following illustration shows the high-level design of Megastore components within a data center.

In this design problem, our primary concern is to provide better transactions with stronger consistency, availability, and scalability. Megastore uses the following two approaches to provide high availability and scalability:

• To improve availability, Megastore uses a fault-tolerant, synchronous log

...