DEV Community: NISCHIT D S

Reliability & Availability

NISCHIT D S — Wed, 09 Sep 2026 03:28:46 +0000

| What's the Difference?

These terms are often confused, but they measure different things:

Reliability : System performs correctly without failure
Availability : System is operational when needed

Analogy: Think of a car:

Reliable = The car doesn't break down during your trip
Available = The car is ready to drive when you need it

A system can be available but unreliable (works but gives wrong results), or reliable but unavailable (works correctly but only 50% of the time).

| Measuring Availability

Availability is typically expressed as a percentage of uptime:

Availability = Uptime / (Uptime + Downtime) × 100%

**Real-world examples:**

Google Search: ~99.99% (four nines)
AWS S3: 99.99% availability SLA
Credit card processing: Often requires 99.999%

| Calculating Composite Availability

For components in sequence (all must work):

A_total = A₁ × A₂ × A₃ × ... × Aₙ

Example: Three services at 99% each in sequence:

0.99 × 0.99 × 0.99 = 97.03%

For components in parallel (any can work):

A_total = 1 - (1 - A₁) × (1 - A₂) × ... × (1 - Aₙ)

Example: Two servers at 99% each in parallel:

1 - (0.01 × 0.01) = 99.99%

| Measuring Reliability

Reliability is measured using these key metrics:

Mean Time Between Failures (MTBF)

Average time the system operates before failing.

MTBF = Total Operating Time / Number of Failures

Example: Server runs for 8760 hours/year with 2 failures

MTBF = 8760 / 2 = 4380 hours

Mean Time To Recovery (MTTR)

Average time to restore the system after failure.

MTTR = Total Downtime / Number of Failures

Lower MTTR = Better availability

Relationship to Availability

Availability = MTBF / (MTBF + MTTR)

Key Insight: You can improve availability by:

Increasing MTBF (fail less often)
Decreasing MTTR (recover faster)

Often, reducing MTTR is easier and cheaper than increasing MTBF!

| Common Failure Modes

Software Failures

Memory leaks - Application crashes over time
Bugs - Incorrect behavior under certain conditions
Deadlocks - System hangs waiting for resources
Resource exhaustion - Disk full, too many connections

Human Errors

Studies show 70-80% of outages are caused by humans:

Configuration mistakes
Deployment errors
Accidental deletions
Security misconfigurations

External Failures

Network partitions
Third-party service outages
Power failures
Natural disasters

| Patterns for High Availability

1. Redundancy : Eliminate single points of failure by duplicating components.

Types of redundancy:

Active-Active: All nodes handle traffic (load sharing)
Active-Passive: Standby nodes take over on failure
N+1: One extra server for every N servers

2. Health Checks & Monitoring : Detect failures quickly to minimize MTTR.

Health check best practices:

Check every 10-30 seconds
Use separate endpoint from main API
Include dependency checks
Set appropriate timeouts

3. Failover Strategies

4. Circuit Breaker Pattern : Prevent cascading failures by stopping calls to failing services.

States:

Closed: Normal operation, requests pass through
Open: Requests fail immediately (no call to service)
Half-Open: Allow limited requests to test recovery

Retry with Exponential Backoff : Handle transient failures gracefully.

def retry_with_backoff(operation, max_retries=5):
    for attempt in range(max_retries):
        try:
            return operation()
        except TransientError:
            wait_time = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait_time)
    raise Exception("Max retries exceeded")

Key points:

- Start with small delay (1s)
- Double each time (1s, 2s, 4s, 8s...)
- Add jitter to prevent thundering herd
- Set maximum retry count

Real-World Architecture: High Availability Database

This architecture provides:

Read scaling via replicas
Automatic failover if primary fails
Point-in-time recovery from S3 backups
Geographic distribution possible

Key Takeaways

Availability measures uptime, Reliability measures correctness
Each "nine" of availability is 10x harder to achieve
Parallel redundancy dramatically improves availability
Reducing MTTR is often easier than increasing MTBF
Human error causes most outages—automate and use guardrails
Circuit breakers prevent cascading failures
SLOs should be based on user needs, not engineering pride

Scalability Principles

NISCHIT D S — Mon, 31 Aug 2026 04:55:25 +0000

| What is Scalability?

Scalability is the ability of a system to handle increased load by adding resources. A scalable system can grow to accommodate more users, more data, or more transactions without a significant degradation in performance.

Think of it like a restaurant:

A small café can serve 20 customers comfortably
As it gets popular, you need to scale
You can make the kitchen bigger (vertical scaling)
Or open more locations (horizontal scaling)

| Why Does Scalability Matter?

Viral growth : Your startup might go viral overnight
Unpredictable traffic : Black Friday, viral content, news events
Cost efficiency : Pay for what you need, when you need it
User experience : Slow apps lose users (53% abandon if >3s load)

| Vertical vs Horizontal Scaling

There are two fundamental approaches to scaling:

Vertical Scaling (Scale Up)

Add more power to your existing machine - more CPU, RAM, or storage.

Before: 4 CPU, 8GB RAM, 100GB Storage
After:  32 CPU, 128GB RAM, 2TB Storage

**Pros Of Vertical Scaling**

- Simple to implement
- No code changes needed
- Lower complexity
- ACID compliance easier

**Cons Of Vertical Scaling**

- Hardware limits exist
- Single point of failure
- Expensive at high end
- Downtime during upgrades

| Horizontal Scaling (Scale Out)

Add more machines to distribute the load.

Before: 1 server handling all traffic
After:  10 servers sharing the load

**Pros Of Horizontal Scaling**

- Theoretically unlimited
- Better fault tolerance
- Cost-effective at scale
- No single point of failure

**Cons Of Horizontal Scaling**

- More complex architecture
- Data consistency challenges
- Requires load balancing
- Network latency between nodes

**Real-World Example: Instagram**

- Started with a single server
- Scaled vertically until they hit limits
- Moved to horizontal scaling with sharded databases
- Now runs on thousands of servers across multiple data centers

| Key Metrics for Scalability
To measure scalability, you need to understand these key metrics:

1. **Throughput** : Requests per second (RPS) your system can handle.

Example: "Our API handles 10,000 RPS"

2. **Latency** : Time taken to process a single request (measured in milliseconds).

Important: P50, P95, P99 percentiles matter more than averages!

P50: 50ms  (50% of requests faster than this)
P95: 100ms (95% of requests faster than this)
P99: 500ms (99% of requests faster than this)

The P99 catches the "unlucky" slow requests that affect user experience.

3. **The Scalability Equation**

Throughput = Concurrency / Latency

If your average latency is 100ms and you have 100 concurrent workers:

Throughput = 100 / 0.1 = 1,000 RPS

4. **Amdahl's Law** : The speedup of a program using multiple processors is limited by the sequential fraction:

Speedup = 1 / (S + (1-S)/N)

Where S = sequential fraction, N = number of processors.

Key Insight: If 10% of your code is sequential, adding infinite processors only gives 10x speedup maximum!

| Common Scalability Patterns

1. **Load Balancing** : Distribute requests across multiple servers to prevent any single server from becoming a bottleneck.

        ┌─────────────────┐
        │  Load Balancer  │
        └────────┬────────┘
       ┌─────────┼─────────┐
       ▼         ▼         ▼
   ┌───────┐ ┌───────┐ ┌───────┐
   │Server1│ │Server2│ │Server3│
   └───────┘ └───────┘ └───────┘

2. **Caching **: Store frequently accessed data in memory for faster retrieval.

Rule of thumb: Cache 20% of data = handle 80% of requests (Pareto principle)

3. **Database Sharding** : Split your database across multiple machines based on a shard key.

Shard Key: user_id

User 1-1M    → Shard A
User 1M-2M   → Shard B  
User 2M-3M   → Shard C

4. **Microservices** : Break your monolith into smaller, independently scalable services.

Monolith: One thing does everything
    ↓
Microservices: Each service scales independently

Auth Service  → 2 instances (light load)
Image Service → 20 instances (heavy load)
API Gateway   → 5 instances (medium load)

5. **Asynchronous Processing **: Use message queues to handle time-consuming tasks.

User Request → API → Queue → Worker → Done!
     ↓
  Quick Response (Task queued!)

Perfect for: Email sending, image processing, report generation

6. **Read Replicas** : Create read-only copies of your database.

┌──────────────┐
│  Primary DB  │ ← Writes
└──────┬───────┘
       │ Replicates
   ┌───┴───┐
   ▼       ▼
┌─────┐ ┌─────┐
│Rep 1│ │Rep 2│ ← Reads
└─────┘ └─────┘

Works great for read-heavy workloads (80%+ reads).

| Stateless vs Stateful Architecture

1. **Stateless Services **: Each request contains all information needed to process it. The server doesn't remember previous requests.

Request: { token: "abc123", action: "getData" }
         ↓
Any Server → Process → Response

**Benefits:**

- Easy to scale horizontally
- Any server can handle any request
- Simple load balancing
- No session affinity required

2. **Stateful Services** : The server maintains client state between requests.

**Challenges:**

- Need sticky sessions or shared state
- More complex failover
- Session storage required

Best Practice: Externalize State

Instead of:
Server Memory → Session Data

Use:
┌─────────┐    ┌───────────┐    ┌─────────┐
│Client A │───▶│  Server 1 │───▶│  Redis  │
└─────────┘    └───────────┘    │ (State) │
┌─────────┐    ┌───────────┐    │         │
│Client B │───▶│  Server 2 │───▶│         │
└─────────┘    └───────────┘    └─────────┘

This gives you the benefits of both: stateful behavior with stateless architecture.

| Real-World Example: Scaling Twitter

Let's see how a real company approached scalability:

The Challenge

- 500 million tweets per day
- Millions of users refreshing feeds
- Celebrity tweets can spike traffic 100x

Solutions Twitter Used

1. Fan-out on Write : When you tweet, it's pre-computed into your followers' timelines.

You tweet → Immediately written to all followers' timeline cache

Trade-off: More storage, but faster reads.

Exception: Celebrities use fan-out on read (accounts with millions of followers).

2. Redis for Timeline Cache : Each user's home timeline is cached. Recent tweets always available instantly.

*3. Separate Read/Write Paths : *

Tweets → Write Cluster (optimized for writes)
Reads  → Read Cluster (optimized for reads)

Eventually consistent (you might not see your tweet for a few seconds).

4. Geographic Distribution : Data centers worldwide. Users routed to nearest location.

| Key Takeaways

Scalability is about handling growth without sacrificing performance
Horizontal scaling **(adding machines) is generally preferred over **vertical scaling (bigger machines)
Stateless architectures are easier to scale than stateful ones
Caching, load balancing, and database sharding are essential patterns
Measure throughput, latency, and availability to track scalability
Real systems use multiple strategies tailored to specific use cases