updates

Signed-off-by: Raj Patil <rajp152k@gmail.com>

Content/20240519200217-quorum.org

@@ -27,7 +27,7 @@ To proceed with an operation, a designated number of nodes must vote in favor of
 
  - Availability: improves availability by allowing operations to proceed even when some nodes are unavailable.
 
-* Types of Quorum
+* Reads & Writes
 
  - Read Quorum: The minimum number of nodes that must respond to a read request before the data is considered valid.
 
@@ -49,5 +49,3 @@ widely used in various distributed systems, including:
 
 Overall, quorum is a powerful tool for managing distributed systems, but it requires careful consideration and configuration to balance consistency, availability, and fault tolerance.
 
-* Misc
- - see [[id:20240519T201001.324666][Merkle Tree]]

Content/20240519201001-merkle_tree.org

@@ -1,5 +1,6 @@
 :PROPERTIES:
 :ID:       20240519T201001.324666
+:ROAM_ALIASES: "Hash Tree"
 :END:
 #+title: Merkle Tree
 #+filetags: :cs:

Content/20240519213730-sstree.org

@@ -4,15 +4,15 @@
 #+title: SS Table
 #+filetags: :data:cs:
 
- - SSTable, short for Sorted String Table, is a simple yet powerful data structure used in many storage systems, including NoSQL databases like Cassandra and LevelDB. It's a fundamental building block for efficient data storage and retrieval.
+ - SSTable, short for Sorted String Table, is a simple yet powerful data structure used in many storage systems, including [[id:972f53f5-0c08-4136-8214-1b62fba60360][NoSQL]] databases like [[id:20240519T221905.005300][Cassandra]] and LevelDB. It's a fundamental building block for efficient data storage and retrieval.
 
  - versatile and efficient [[id:20230715T173535.681936][data structure]] that plays a crucial role in many storage systems, particularly those that require high performance and scalability.
 
 * Key Characteristics
 
  - Sorted: Data within an SSTable is sorted by keys, making it easy to find specific records using binary search.
 
- - Immutable: Once created, an SSTable cannot be modified. This immutability simplifies concurrency control and allows for efficient merging of multiple SSTables.
+ - [[id:efba8f9b-a5df-4212-94c9-230bef916b5c][Immutable]]: Once created, an SSTable cannot be modified. This immutability simplifies concurrency control and allows for efficient merging of multiple SSTables.
 
  - Persistent: SSTables are typically stored on disk for long-term persistence.
 

Content/20250120164743-gossip_protocols.org

@@ -3,3 +3,36 @@
 :END:
 #+title: Gossip Protocols
 #+filetags: :network:cs:
+
+* Overview
+
+- *Definition*: Gossip protocols are decentralized communication protocols used in [[id:a3d0278d-d7b7-47d8-956d-838b79396da7][distributed]] systems to disseminate information in a manner akin to how gossip spreads in social settings.
+
+- *Characteristics*:
+  - *[[id:b4b52e81-fc9e-4c62-89ab-8ea199fe77eb][Decentralization]]*: No single point of failure; all nodes have equal responsibility.
+  - *[[id:56dbce77-b258-4fde-a6c7-f865e476c879][Scalability]]*: Efficiently shares information regardless of the number of nodes.
+  - *Robustness*: Resilient to node failures and can adapt to dynamic changes in the network.
+  - *[[id:b2ce2739-98c4-4ff0-931c-3a836686bf55][Asynchronous]]*: Nodes do not need to operate in sync, reducing bottleneck effects.
+
+- *Types of Gossip Protocols*:
+  - *Push-based*: Nodes actively send messages to a selected subset of peers.
+  - *Pull-based*: Nodes request information from other nodes, typically when they feel they need data.
+  - *Hybrid*: Combines aspects of both push and pull methods for optimized dissemination.
+
+- *Use Cases*:
+  - *[[id:8cd19397-b5e5-40b6-a172-456c34985a11][Database replication]]*: Ensuring data consistency across distributed database systems.
+  - *Peer-to-peer networks*: Distributing resources or information among participating nodes.
+  - *Monitoring systems*: Collecting status updates and health checks across nodes in large networks.
+
+- *Advantages*:
+  - *Reduced bandwidth consumption*: By selectively sending updates.
+  - *[[id:20240519T162542.805560][Fault tolerance]]*: Nodes can join or leave without greatly impacting the overall system.
+  - *Fast data dissemination*: Information can spread rapidly even in large networks.
+
+- *Challenges*:
+  - *Inexact state*: Nodes may have outdated or inconsistent views of the data.
+  - *Message overhead*: Inefficiencies can arise during large-scale data transmissions.
+  - *Security*: Susceptible to malicious attacks if not properly designed.
+
+* Resources
+ - https://en.wikipedia.org/wiki/Gossip_protocol

Content/20250128160111-consistency.org

@@ -7,6 +7,8 @@
 
 See [[id:20240519T152842.050227][CAP]]
 
+* Inconsistency Detection
+** [[id:20240519T201001.324666][Merkle Tree]]
 * Inconsistency Reconciliation
 ** [[id:038e3720-0307-41d8-bcb1-e77b75a161df][Versioning]]
 * Relevant Nodes

Content/20250128172055-failure_detection.org

@@ -20,18 +20,22 @@
 
  - Crash Failures: A node stops responding completely.
  - Omission Failures: A node fails to send or receive messages.
- - Byzantine Failures: A node behaves arbitrarily or maliciously.
+ - [[id:7a45b00c-b5fc-4132-a572-db798a5078d2][Byzantine Failures]]: A node behaves arbitrarily or maliciously.
 
 * Failure Detection Mechanisms
 
- - Heartbeating: Nodes periodically send "I'm alive" messages to a central monitor or each other. Absence of heartbeats indicates a potential failure.
+ - Heart-beating: Nodes periodically send "I'm alive" messages to a central monitor or each other. Absence of heartbeats indicates a potential failure.
 
  - Ping/Echo: A node sends a ping message, and the other node replies with an echo. Lack of response suggests a failure.
 
- - Gossip Protocols: Nodes exchange information about the health of other nodes, spreading failure information quickly.
+ - [[id:f82e5b8d-a4a4-4f0b-be4e-49d5fd676dc3][Gossip Protocols]]: Nodes exchange information about the health of other nodes, spreading failure information quickly.
 
  - Timeout-Based Detection: If a node doesn't respond within a certain time, it's assumed to have failed.
 
+ - [[id:2cf696b9-cdd3-473b-8aff-adccc54cccdf][Anti-Entropy Protocols]]
+
+
+
 * Failure Detector Properties
 
  - Completeness: Every actual failure is eventually detected.

Content/20250128180156-byzantine_failure.org

@@ -0,0 +1,9 @@
+:PROPERTIES:
+:ID:       7a45b00c-b5fc-4132-a572-db798a5078d2
+:ROAM_ALIASES: "Byzantine General's Problem" "Byzantine Fault"
+:END:
+#+title: Byzantine Failure
+#+filetags: :cs:meta:
+
+* Resources
+ - https://en.wikipedia.org/wiki/Byzantine_fault

Content/20250128181152-decentralization.org

@@ -0,0 +1,5 @@
+:PROPERTIES:
+:ID:       b4b52e81-fc9e-4c62-89ab-8ea199fe77eb
+:END:
+#+title: Decentralization
+#+filetags: :meta:

Content/20250128182043-sloppy_quorum.org

@@ -0,0 +1,34 @@
+:PROPERTIES:
+:ID:       12ea2ca7-31e6-4ba7-834f-db7560f8075a
+:END:
+#+title: Sloppy Quorum
+#+filetags: :cs:
+
+* Overview
+
+- *Definition of Sloppy [[id:20240519T200217.994784][Quorum]]*:
+  - A system design pattern commonly used in distributed systems.
+  - It allows for read or write operations to succeed even when some nodes in the cluster are down or unreachable.
+
+- *Key Characteristics*:
+  - Offers high [[id:cba21706-d0d4-4044-8cf1-cbafadad899f][availability]] and [[id:20240519T162542.805560][fault tolerance]].
+  - Data replication across multiple nodes enhances resiliency.
+  - Reduced consistency guarantees in exchange for availability.
+
+- *The Role of Quorum*:
+  - A traditional quorum requires a majority of nodes to respond for an operation to succeed.
+  - Sloppy quorum relaxes this criterion, allowing operations to proceed with responses from fewer nodes or even from nodes that are not part of the intended quorum.
+
+- *Use Cases*:
+  - Often implemented in systems where speed and uptime are prioritized over strict consistency, such as in NoSQL databases.
+  - Can be beneficial in managing transient failures or network partitions.
+
+- *Trade-offs*:
+  - While it improves availability, it may lead to stale reads or temporary inconsistencies in the system.
+  - Use requires careful consideration of the acceptable level of inconsistency for the application in question.
+
+* Relevant Node
+** [[id:21124361-2f72-4270-9bfe-f12f52155476][Hinted Handoff]]
+* Resources
+ - https://distributed-computing-musings.com/2022/05/sloppy-quorum-and-hinted-handoff-quorum-in-the-times-of-failure/
+ - https://scalablehuman.com/2021/11/23/distributed-data-intensive-systems-sloppy-quorums-and-hinted-handoffs/

Content/20250128182136-availability.org

@@ -0,0 +1,6 @@
+:PROPERTIES:
+:ID:       cba21706-d0d4-4044-8cf1-cbafadad899f
+:ROAM_ALIASES: "High Availability" HA
+:END:
+#+title: Availability
+#+filetags: :cs:

Content/20250128183028-anti_entropy_protocols.org

@@ -0,0 +1,29 @@
+:PROPERTIES:
+:ID:       2cf696b9-cdd3-473b-8aff-adccc54cccdf
+:END:
+#+title: Anti-Entropy Protocols
+#+filetags: :cs:
+
+* Overview
+
+- *Definition*:
+  - Anti-entropy protocols are methods used in [[id:a3d0278d-d7b7-47d8-956d-838b79396da7][distributed]] systems to ensure data [[id:e833eafc-e622-4631-a1ee-f9c679a4d71d][consistency]] across nodes.
+
+- *Purpose*:
+  - They help reconcile differences between [[id:8cd19397-b5e5-40b6-a172-456c34985a11][replicas]], particularly in systems where data may diverge due to concurrent writes or network failures.
+
+- *Mechanisms*:
+  - These protocols typically involve periodic checks of data states across nodes, followed by synchronization to resolve discrepancies.
+
+- *Types*:
+  - *Push-based*: One node sends its data state to others.
+  - *Pull-based*: Nodes request updates from one another.
+  - *Hybrid*: Combines both push and pull mechanisms.
+
+- *Application*:
+  - Commonly used in distributed databases (e.g., [[id:4f6c9fa4-ab8c-48da-a412-27a5a5867a21][Dynamo]], [[id:20240519T221905.005300][Cassandra]]) and [[id:20240519T201442.376294][peer-to-peer]] networks.
+
+- *Challenges*:
+  - [[id:aa3f4461-08f4-4a3d-ae4b-5704d1f3dd23][Latency]]: Ensuring prompt updates can be difficult in large networks.
+  - [[id:e8f3c721-0dba-4dc7-803f-263e88a47596][Network Partitioning]]: Handling situations where network splits can lead to divergent state.
+  - Performance: Balancing consistency checks without overloading the system.

Content/20250128184412-network_partitioning.org

@@ -0,0 +1,8 @@
+:PROPERTIES:
+:ID:       e8f3c721-0dba-4dc7-803f-263e88a47596
+:END:
+#+title: Network Partitioning
+#+filetags: :cs:
+
+* Relevant Nodes
+** [[id:20240519T152842.050227][CAP]]