Introduction of Availability

Availability is really necessary in todays systems because if any part of your system is not available, according to CAP theorem its going to cause data inconsistency. This calls for the need of High Availability.

---

What do you mean by High Availability?

Well high availability basically means your system is going to be available as much of the time as possible. There are a few pattern you can use to ensure this high availability. While ensuring high availability we ensure as minimum downtime as possible and it is measured by the percentage of time its uptime.

---

Ensuring High Availability: Factors and Design Principles

Achieving high availability requires understanding the bad influences on system uptime and applying resilient architectural practices. Let's talk about each of them in short:

Factors Affecting Availability

1. Hardware Reliability
   Failures in servers, network devices, or storage directly impact availability. Reliable hardware and redundant configurations are essential.

2. Software Stability
   Bugs or crashes in the OS, middleware, or application stack can cause outages. Stable, well-tested software is critical.

3. Network Infrastructure
   Downtime or latency in switches, routers, or connectivity affects accessibility. Reliable networking supports continuous service delivery.

4. Redundancy and Failover
   Backup systems and automatic failover (e.g., load balancers, clustering) ensure continuity during component failures.

5. Monitoring and Alerting
   Real-time monitoring and alerts enable proactive detection and resolution of issues before they escalate.

6. Maintenance Practices
   Regular updates, patches, and system checks prevent unplanned outages from known vulnerabilities or degradation.

7. Scalability
   Systems must dynamically handle increased loads to maintain availability during peak usage.

---

Design Principles for High Availability

1. Redundancy
   Duplicate critical components (hardware, services, data) to eliminate single points of failure.

2. Fault Tolerance
   Design systems to recover automatically from failures using self-healing mechanisms and resilient architectures.

3. Load Balancing
   Distribute traffic evenly to prevent overload on any single node, enhancing both performance and uptime.

4. Scalability
   Support vertical and horizontal scaling to meet growing demand without degrading service.

5. Isolation and Modularity
   Separate system components so that failures are contained and do not affect the entire system.

6. Automated Monitoring and Recovery
   Use observability tools and auto-remediation to reduce downtime and manual intervention.

7. Microservices Architecture
   Decompose applications into independently deployable services that can scale and fail independently.

8. Distributed Systems
   Spread services and data across regions or nodes using replication and sharding to withstand localized failures.

9. Containerization and Orchestration
   Use containers (e.g., Docker) and orchestrators (e.g., Kubernetes) to manage scalable, resilient deployments with automated recovery.

10. Event-Driven Architecture (EDA)
    Enable asynchronous, decoupled communication through events, promoting fault isolation and flexible scaling.

---

Measuring Availability

There are a few metrices to measure availability in systems. These are:

1. Uptime Percentage: The percentage of time the system is available. A higher uptime means the system is highly available.
2. Mean Time Between Failures(MTBF): The average time between system failures. A higher MTBF means highly available and reliable system.
3. Mean Time To Repair(MTTR): The average time it takes to repair a system failure. A higher MTTR represents lower availability.

Availability Patterns

Active - Active Pattern

The active-active pattern is a strategy where multiple instances are spun simultaneously. This allows high scalability and availability as multiple instances are distributing the workload. Think of it like having multiple cashiers open at a supermarket – all serving customers at the same time. This isn't just about having backups; it's about all hands on deck, all the time. Load balancers are crucial here, smartly directing traffic to ensure no single instance gets swamped. The big win? If one instance hiccups, the others just pick up the slack, often without users even noticing. The challenge? Keeping data consistent across all active instances can be tricky.

Bookish Definition: Active-Active refers to a system architecture where all redundant components are operational and actively processing requests or data simultaneously, typically facilitated by a load balancer to distribute traffic and enhance overall system capacity and resilience.

Active - Passive Pattern

The active-passive pattern suggests that there is an active instance which is always running and then there is a passive instance which can be spun up instantly when the need arises (system failure). This provides failover capabilities and efficient resource utilization. This is your classic 'understudy' scenario. The main actor (active instance) is on stage, doing all the work. The understudy (passive instance) is backstage, ready to jump in at a moment's notice if the main actor trips. The passive instance is often kept in sync with the active one (e.g., via data replication) so it's not starting from scratch. While it's more resource-efficient than active-active (the passive one isn't doing much until it's needed), there's a small delay during the switchover.

Bookish Definition: Active-Passive describes a high-availability configuration where one system or component (the active node) handles the entire workload, while a redundant system or component (the passive node) remains in a standby state, ready to take over operations if the active node fails, thus ensuring service continuity.

Failover Pattern

In failover pattern we make an Instance to take over when the primary instance fails. This might seem just like the Active-Passive pattern and it is, because active-passive is the subset of failover pattern. You nailed it – active-passive is a type of failover. Failover itself is the broader concept: having a plan B (and C, and D...) when plan A goes sideways. It's the capability of a system to automatically switch to a redundant or standby server, system, or network upon the failure or abnormal termination of the previously active application, server, system, or network. The goal is business continuity, pure and simple. How fast and seamless this switch happens (the Recovery Time Objective or RTO) is a big deal here.

Bookish Definition: Failover is a fault tolerance mechanism that automatically switches operations to a standby or redundant system when a primary system component fails, aiming to minimize downtime and maintain service continuity by transferring the workload to the backup component.

Replication Pattern

In replication pattern we make replicas of same data across multiple centers to ensure data redundancy and availability. Exactly! It's like making photocopies of a crucial document and storing them in different safe locations. If one copy gets destroyed, you've got others. This isn't just for disaster recovery; replicas can also be used to serve read traffic, taking load off the primary database. You can have synchronous replication (writes confirmed on all replicas before success – safer, but slower) or asynchronous (writes confirmed on primary, then copied – faster, but tiny risk of data loss on immediate primary failure).

Bookish Definition: Replication is the process of creating and maintaining multiple copies of data (replicas) on different storage devices or servers to improve data availability, fault tolerance, and potentially read performance by distributing read queries. It can be synchronous or asynchronous.

Sharding Pattern

In sharding pattern we make multiple smaller parts of our data which are called shards which can then be distributed across multiple servers. Spot on. Imagine a massive library. Instead of one giant catalog, you divide books by genre (or author, or publication year – that's your 'shard key'), and each section has its own smaller, manageable catalog. This is sharding for databases. When your dataset gets too big for a single server to handle efficiently, you chop it up (horizontally partition it) into these smaller, faster, more manageable pieces called shards. Each shard lives on its own server. Great for scaling out databases, but queries that need data from multiple shards can get complex.

Bookish Definition: Sharding, also known as horizontal partitioning, is a database architecture technique where a large dataset is divided into smaller, more manageable pieces called shards, with each shard being stored on a separate database server or instance, enabling distribution of load and improved scalability.