liveBook · Manning

Redundancy

As explained in ScyllaDB in Action

Redundancy is the inclusion of duplicate data or components so that a system can continue operating when one becomes unavailable.

Redundancy stores duplicate data or components so a system can continue serving requests when one component becomes unavailable. Multiple holders coordinate to keep their copies current. section 1.1.1

ABC Data

ABC Data assigns each customer’s data to multiple employees. If Charlotte is unavailable, Alice and Bob handle requests; when Charlotte returns, they bring her copy up to date. Three holders can require all responses for the newest answer, one for immediate availability, or two to balance correctness and availability. section 1.1.1

Figure 1.5 ABC Data’s approach gives you control over availability and correctness.
figure

Use the figure to compare response requirements and the resulting trade-off between availability and correctness. section 1.1.1

How ScyllaDB in Action covers it

How deep it goes
Explains duplicate copies, holder coordination, unavailable nodes, scaling, and response-count trade-offs.
Examples
Uses ABC Data employees, three data holders, an unavailable Charlotte, and one-, two-, or three-holder responses.
What you can do after
Evaluate how response requirements balance immediate availability against the newest available data.
How it connects
Connects redundancy with availability, correctness, coordination, and distributed scaling.

Also explained in

Compare how 6 books explain redundancy →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.