Benefits and Drawbacks

Learn about the benefits and drawbacks of shared-nothing architecture.

We'll cover the following

Benefits

The shared-nothing architecture provides many benefits from a performance and fault-tolerance perspective. It provides scalability and availability guarantees.

Scalability

All layers of the applications can be incrementally scaled out or in depending on the load.

Note: Scalability is easier and quicker to achieve in the stateless components since it requires less data transfer.

Availability

The system is resilient to single-node and multi-node failures.

More specifically, these two different forms of failure impact the stateless parts of the system in a similar way. The size of the impact is just different. For example, the remaining nodes might need to handle a bigger load, or more servers might need to be provisioned.

For the stateful parts of the architecture, single and multi-node failures have slightly different behaviors.

  • Single-node failures are a lot easier to handle since each partition can use a consensus-based technique for replication which can remain fully functional as long as a majority of nodes is healthy.
  • However, multi-node failures can affect a majority, thus making a partition unavailable

Note: Even in this case, the good thing is only this partition will be unavailable, and the rest of the system’s data will still be available.

Supporting the problems that are amenable to partitioning

Shared-nothing architecture tends to be a good fit for problems that are amenable to fine-grained partitioning.

Some examples of problems in this space are:

  • Managing user sessions
  • Managing the products of a catalog

In both cases, data can easily be partitioned in a way where data access operations will need to access a single data item.

  • Sessions can be assigned a unique identifier, and this attribute can partition them.
  • Products can be partitioned according to a similar product identifier.

If sessions and products are mostly retrieved and updated by their identifier, they can be done efficiently by querying only the nodes with the associated data.

Concurrency control

There is also space for some form of limited concurrency control in the scope of a partition.

For cases where single-item access is the norm, a common technique is using the optimistic concurrency control to reduce overhead and contention. It is be achieved by including a version attribute on every data item. Every writer performs a read before a write to find the current version and then includes the current version in the update as a condition to be satisfied for it to be completed.

Of course, this requires the corresponding datastore to provide support for conditional updates. If a concurrent writer has updated the same item in the meanwhile, the first writer will have to abort and restart by performing a new read to determine whether its initial write should still apply and, if so, retry it.

Drawback of a shared-nothing architecture

Along with the benefits described above, shared-nothing architecture has some drawbacks also…

The main drawback is reduced flexibility. If the application needs access to new data access patterns efficiently, it might be hard to provide it given the system’s data have been partitioned in a specific way.

For example, attempting to query by a secondary attribute that is not the partitioning key might require access to all the nodes of the system. This reduced flexibility might also manifest in a lack of strong transactional semantics.

Applications that need to perform reads of multiple items with strong isolation or write multiple items in a single atomic transaction might not do this under this form of architecture. It might only be possible at the cost of excessive additional overhead.

Get hands-on with 1400+ tech skills courses.