Website Availability and High‑Availability Architecture Overview

1. Measuring and Assessing Website Availability

Website availability describes the ability of a site to be accessed effectively. Downtime (failure time) is calculated as the difference between the failure detection/report time and the failure recovery time. Annual availability is expressed as (1 - downtime/total time) × 100%.

Availability is a key architectural metric, serving as an external service commitment and an internal performance indicator, often quantified through fault points.

Fault points weight different failure categories:

Category

Description

Weight

Accident‑level fault

Severe fault causing complete site outage

100

Class A fault

Core functionality unavailable or site access is poor

20

Class B fault

Non‑core functionality unavailable or only a few users affected

5

Class C fault

Other faults

1

Fault points are calculated as: Fault Points = Fault Duration (minutes) × Fault Weight

2. High‑Availability Website Architecture

A typical website follows a three‑tier model (presentation, application, data). In large‑scale deployments, each tier may be further subdivided, but the core principle remains the same.

Application‑layer servers are clustered behind load balancers; if a server becomes unavailable, the balancer removes it from the pool, ensuring continuous service.

Service‑layer servers operate similarly, accessed via distributed service frameworks that provide client‑side load balancing.

Data‑layer servers require replication to guarantee data durability and uninterrupted access, often using synchronous writes to multiple nodes.

Frequent site releases cause planned downtime, so the architecture must also accommodate upgrade‑related outages.

3. High‑Availability Application Layer

The application layer handles business logic and is typically stateless, simplifying load balancing. However, session management becomes complex in clustered environments.

Session handling techniques include:

3.1 Session Replication

Servers synchronize session objects across the cluster, storing full session data on each node. This approach is simple but can consume excessive resources at scale.

3.2 Session Affinity (Sticky Sessions)

Load balancers use source‑IP hashing to route a user’s requests to the same server, keeping the session local.

3.3 Cookie‑Based Session Tracking

Session identifiers are stored in client‑side cookies and sent with each request; the server updates the session and returns the modified cookie.

3.4 Dedicated Session Server

Sessions are managed by a separate server or cluster (e.g., distributed cache, database), decoupling state from the application servers.

4. High‑Availability Services

Reusable service modules are stateless and can be load‑balanced with failover strategies. Additional best practices include hierarchical management, timeout settings, asynchronous calls, and service degradation during peak loads.

5. High‑Availability Data

Data reliability is achieved through backup and failover mechanisms, adhering to the CAP theorem (Consistency, Availability, Partition tolerance).

6. Quality Assurance for High‑Availability Sites

The deployment pipeline includes steps to minimize downtime during releases; a diagram (omitted) illustrates the process.

7. Website Operational Monitoring

Monitoring is mandatory for reliable operation. Key metrics include user behavior logs, server performance (CPU, memory), and runtime data such as cache hit rates, average response times, email throughput, and pending task counts.

Collected data supports capacity planning, risk alerts, automatic failover, and dynamic load adjustment to maximize resource utilization.