Redundancy & Replication

Question 1

Redundancy

Answer 1

It is the duplication of critical components or functions of a system with the intention of increasing the reliability of the system. It means adding extra components (servers, systems, databases, etc.) so that if one part fails, the system continues to function without interruption.

Redundancy plays a key role in removing the single points of failure in the system and provides backups if needed in a crisis. For example, if we have two instances of a service running in production and one fails, the system can failover to the other one.

✅ Why Redundancy Matters

🛡️ High Availability:Keeps services running even if part of the system fails
📉 Fault Tolerance:Reduces the chance of total system downtime
🚀 Improved Reliability:Ensures users experience minimal disruption during outages or failures
🔁 Automatic Failover Traffic is redirected to backup systems automatically

It can be Server Redundancy, db redundancy, Network Redundancy and Geographic Redundancy (Systems distributed across regions (e.g., AWS Multi-AZ or Multi-Region): Protects against regional outages or disasters

Question 2

Database Replication

Answer 2

Database replication is the process of copying data from one database server (primary) to one or more other servers (replicas) so that all of them have the same data, either in real-time or near real-time.

🔁 Why Use Database Replication?

📈 Scalability:You can spread read traffic across replicas (read scaling)
🛡️ High Availability: If the primary fails, a replica can take over (failover)
🧠 Backup & Recovery Replicas serve as real-time backups
🚀 Performance:Reads can be served from closer geographic locations (geo-replication)
🧪 Testing / Analytics: Use replicas for reporting or testing without affecting the main database

Types of dB Replication
a) Synchronous replication: Synchronous replication is a type of database replication in which every write operation to the primary database is only considered successful after it has been fully replicated to all replica databases.

The primary database waits for confirmation from the replicas that they have received and applied the changes before acknowledging the write to the client.

🧠 Key Characteristics
✅ Strong consistency: All replicas have the exact same data at all times.

✅ Minimal risk of data loss: Even if the primary crashes, replicas are fully up to date.

🚫 Higher latency: Since the primary must wait for acknowledgments from replicas, write performance may be slower.

📦 Use Cases
a)Financial systems (e.g., banking, trading platforms)
b)Critical data storage (e.g., medical records)
c)Any system where data accuracy and consistency is more important than speed

Asynchronous replication is a type of database replication in which changes made to the primary database are not immediately replicated to the replica databases. Instead, the changes are queued or logged, and the replication to the replicas occurs after the primary has already acknowledged the write operation.

🧠 Key Characteristics
🕓 Eventual consistency: Replicas will eventually catch up, but they may lag behind the primary.

🚀 Faster write performance: Since the primary doesn’t wait for replica acknowledgment, write operations complete more quickly.

🔄 Fault tolerance: Even if replicas are temporarily unavailable, writes can still be processed by the primary.

⚠️ Risk of data loss: If the primary crashes before replication completes, some recent changes may not be reflected in the replicas.

📦 Use Cases
a)Systems prioritizing low-latency writes over immediate consistency (e.g., analytics, logging systems)
b)Geographically distributed replicas where latency makes synchronous replication impractical
c)Applications that can tolerate temporary inconsistencies

Feature Synchronous Asynchronous
Consistency Strong Eventual
Write Latency Higher (waits for replicas)Lower (does not wait for replicas)
Replica Lag No Yes
Risk of Data Loss Minimal Possible during failover
Use Case Banking, critical data Analytics, caching

Replication lag: The difference between the primary’s current log position and the replica’s last applied log position tells

Important: If there is a replication lag, howe come replicas sync later with the primary db in the Async replication

Flow:

a)✅ Primary database processes the write:

The write is completed and acknowledged to the client immediately (without waiting for replicas).
The change is recorded in a transaction log.

b) 📨 Replica fetches the changes:

Each replica pulls the changes from the primary’s log on its own schedule.This happens in batches or streams, depending on the setup.

c)🔁 Replica applies the changes locally:

The replica replays those operations in order to keep its data in sync with the primary.

It may lag if:
Network latency exists
The replica is overloaded
Many writes are coming in quickly

d)🟢 Eventually, it catches up:

As long as the replica continues reading and applying the primary’s logs, it will eventually become consistent with the primary.

How Lag is Tracked
Databases like MySQL and PostgreSQL often provide:

a)Replication lag time (in seconds)

b)Current log position vs replica’s last applied position

This allows monitoring tools to detect delays and trigger alerts.

Semi-synchronous replication is a replication strategy that blends the strengths of both synchronous and asynchronous replication.

In this model:

The primary database waits for acknowledgment from at least one replica before confirming a write operation to the client.
Other replicas may be updated asynchronously, after the write is committed on the primary.

🧠 Key Characteristics

⚖️ Balance of performance & safety:Waits for one replica, not ALL → faster than full sync but safer than async
✅ Reduced data loss risk:At least one replica has the latest change before the client gets acknowledgment
⏳ Lower latency than full sync: Doesn’t wait for all replicas to confirm the change
⚠️ Still eventual consistency: Other replicas may lag slightly (like in async)

Common Use Cases
a)Systems that can’t afford total data loss (e.g., financial apps)

b)When performance is still a concern but stronger guarantees than async are needed

c)Databases that support this mode: MySQL, PostgreSQL