Availability vs Consistency

Why It Matters

When your system scales across multiple servers or regions, things break.

Network failures happen. Servers go down. Data gets out of sync.

At that moment, your system must choose:

• stay available and return some data
• or block requests to keep data perfectly consistent

This is a core decision in system design interviews and real systems.

What This Concept Actually Means

Consistency

All users see the same data at the same time.

Example:

• You update your profile name
• Every user immediately sees the updated name

Availability

System always responds to requests, even during failures.

Example:

• System returns a response even if some servers are down

Think like this:

• Consistency = correct data
• Availability = always responding

How It Works (With Example)

Let’s take a banking system.

Scenario: Transfer 1000 rupees

User A sends money to User B.

Strong Consistency Approach

• System ensures both accounts update together
• If database is slow or node fails, request is blocked

Result:

• Data is always correct
• But system may reject or delay requests

High Availability Approach

• System allows request even if some nodes are not synced
• Data may take time to reflect everywhere

Result:

• System always responds
• But temporary inconsistencies happen

Example numbers:

• Replication delay: 2 seconds
• During those 2 seconds, some users may see old balance

Flow:

Diagram
100%
flowchart LR
  User --> API
  API --> PrimaryDB
  PrimaryDB --> ReplicaDB
Zoom or open fullscreen for a closer look
visualized by

Key Techniques / Variations

1. Strong Consistency

• Immediate data correctness
• Used in banking and payments

Trade-off:

• higher latency

2. Eventual Consistency

• Data becomes consistent over time

Example:

• social media likes count

3. Read Replicas

• Improve availability
• Reads served from replicas

Trade-off:

• slightly stale data

4. Quorum Systems

• Majority of nodes must agree

Example:

• 3 nodes, at least 2 must respond

Trade-offs and Design Decisions

When to prioritize consistency

• financial systems
• inventory systems

When to prioritize availability

• social media
• content platforms

Pros of consistency

• accurate data
• avoids critical errors

Pros of availability

• better user experience
• system rarely fails

Cons

• strong consistency increases latency
• high availability may show stale data

Architecture / Flow Diagram

Diagram
100%
flowchart LR
  Client --> LoadBalancer
  LoadBalancer --> AppServer
  AppServer --> PrimaryDB
  PrimaryDB --> Replica1
  PrimaryDB --> Replica2
Zoom or open fullscreen for a closer look
visualized by

Failure Modes To Watch

• replication lag causing stale reads
• network partition between nodes
• conflicting writes
• blocking requests due to strict consistency

Design Checklist

Ask yourself:

• Is stale data acceptable?
• What is the maximum acceptable delay? (e.g., 1 to 5 seconds)
• What happens during network failure?
• Do I need strong consistency for critical operations?
• Can I use eventual consistency safely?

Summary

• Consistency ensures same data everywhere
• Availability ensures system always responds
• You often cannot guarantee both during failures
• Choose based on system requirements
• Real systems mix both depending on use case