Two ideas — fault tolerance and high availability — grow out of one simple, ancient instinct: keep the work going, even when a part breaks. Software architecture inherits that instinct almost unchanged from telephone exchanges, flight decks, and hospital wards.

Imagine you run a small tea stall. If your only stove breaks, you cannot make tea anymore — your business stops. Now imagine you own two stoves side by side. If one breaks, you quietly switch to the other and keep serving customers. Your customers never even notice anything went wrong.

That simple idea — having a backup so that a single broken part does not stop the whole business — is the seed from which two very important ideas in computer systems grew: fault tolerance and high availability. People often use these two terms as if they mean the same thing. They do not. They are cousins, not twins. This guide will walk you through both, slowly and carefully, so that by the end you can explain the difference to a five-year-old, to your manager, and to an interview panel.

The history of these ideas goes back much further than the internet. In the 1940s and 1950s, telephone exchanges and early computers used physical relays and vacuum tubes that failed often. Engineers building telephone switching systems for companies like Bell Labs realised that if a phone call could not be dropped just because one piece of hardware failed, they needed systems that kept working even when parts broke. This early work on “fault tolerant computing” gave birth to ideas like redundant hardware, error-correcting codes, and voting systems where multiple copies of a calculation were compared and the majority answer was trusted.

In the 1970s and 1980s, as banks, airlines, and stock exchanges started depending on computers for critical operations, the idea of “uptime” became a business requirement, not just an engineering nicety. Companies started writing contracts called Service Level Agreements (SLAs) that promised systems would be available a certain percentage of the time — for example, 99.9% of the year. This is where the modern idea of “high availability” as a measurable, promised number really took shape.

Today, with cloud computing, global user bases, and services like Netflix, Amazon, and Uber running 24 hours a day across every time zone, both fault tolerance and high availability are core skills for any software architect. A single hour of downtime for a major e-commerce site during a sale event can cost millions of dollars and, just as importantly, customer trust. So these are not academic concepts — they are the difference between a service that survives failure calmly and one that falls apart in a crisis.

Every piece of hardware and every line of software can fail. The question is never whether — only when, and how badly.

Hard disks crash. Network cables get unplugged by a careless cleaner. Power supplies burn out. Data centres lose electricity during storms. Even software has bugs that cause it to crash under specific conditions nobody predicted. This is simply reality — not a hypothetical “what if,” but something that happens every single day across every company running servers.

If you build a system assuming nothing will ever break, you are building a system that is guaranteed to fail its users eventually — the only question is when, and how badly. The motivation behind both fault tolerance and high availability is the same starting point: failure is not an exception, it is a certainty. The real engineering question is not “how do we prevent failure” (you cannot, completely) but “how do we make sure failure does not hurt our users.”

Businesses care about this because downtime has a direct, measurable cost. An online store that is unreachable during a flash sale loses direct revenue for every minute it is down. A banking app that fails during salary day loses customer trust that can take years to rebuild. A healthcare system that goes down can, in the worst cases, put lives at risk. This is why terms like “five nines” (99.999% availability) are not just buzzwords — they map directly to real financial and reputational outcomes.

The jump from 99.9% to 99.999% sounds small on paper but is enormous in engineering effort and cost, because each additional “nine” typically requires new layers of redundancy, automation, and fault-tolerant design. Understanding the difference between fault tolerance and high availability helps you spend your engineering budget wisely instead of throwing money at the wrong problem.

Before comparing the two ideas, it helps to have crisp working definitions of each on its own. Both are strategies for surviving failure; each takes a different bargain with cost, complexity, and user experience.

3.1 What Is Fault Tolerance?

Fault tolerance is the ability of a system to keep operating correctly, without any noticeable interruption, even when one or more of its components fail. The key words are “correctly” and “without interruption.” A truly fault-tolerant system does not just recover quickly — it never actually goes down at all, because it was built with enough internal redundancy to absorb the failure silently.

Fault tolerance usually works through techniques like:

• Redundancy: having multiple copies of critical components (multiple servers, multiple disks, multiple power supplies) so that if one fails, others immediately take over the exact work in progress.
• Replication with real-time sync: data is copied to multiple places at the same time, so no data is lost if one copy disappears.
• Error detection and correction: techniques like checksums and parity bits that let a system notice when data has been corrupted and fix it automatically.
• Graceful degradation: if part of the system fails, the system keeps working but perhaps with slightly reduced features, rather than crashing entirely.

3.2 What Is High Availability?

High Availability (HA) is the practice of designing a system so that it stays accessible and operational for the largest possible percentage of time, minimising both planned and unplanned downtime. Unlike fault tolerance, high availability does not promise “zero interruption.” It promises “very little total downtime,” and it is measured over time — usually as a percentage per month or per year.

High availability usually works through techniques like:

• Failover: when the primary server fails, traffic is automatically redirected to a standby server within seconds.
• Load balancing: spreading requests across many servers so that if one goes down, the others simply absorb more traffic.
• Health checks and auto-healing: automated systems constantly check if servers are healthy and replace unhealthy ones without a human needing to intervene.
• Geographic redundancy: running copies of the system in multiple data centres or regions so a disaster in one location does not take the whole service down.

Now that you know both definitions, let us put them next to each other so the contrast becomes crystal clear.

Let us look at what actually gets built inside a system to achieve each property. The building blocks differ because the promises differ.

5.1 Building Blocks of Fault Tolerance

• Redundant Array of Independent Disks (RAID): disks store data with extra parity information so any single disk failure can be reconstructed instantly.
• Active-Active Replication: two or more servers process the same requests simultaneously and their results are compared or merged, so if one dies mid-request, the other has already produced the answer.
• Redundant Power Supplies and Network Interfaces: servers in data centres often have two power supplies and two network cards, each connected to a different source, so a single failure does not cut the machine off.
• Error-Correcting Memory (ECC RAM): automatically detects and fixes small memory corruption without crashing the application.

5.2 Building Blocks of High Availability

• Load Balancer: a component that distributes incoming requests across multiple servers and stops sending traffic to servers that fail health checks.
• Active-Passive Failover Cluster: a primary server does the work; a passive standby server is ready to take over the moment the primary is detected as unhealthy.
• Multi-Availability-Zone / Multi-Region Deployment: copies of the application run in physically separate data centres so a power outage or network issue in one location does not bring down the whole service.
• Health Check & Orchestration Systems: tools like Kubernetes constantly monitor whether application instances are alive and automatically restart or replace unhealthy ones.

In the diagram above, notice that Server 3 has failed, but the load balancer has already stopped routing traffic to it. Users connected through Servers 1 and 2 notice nothing. This is a classic high-availability pattern: detect, reroute, continue. The database also has a standby replica ready to be promoted if the primary database fails.

Here, the same request is processed by three independent compute nodes at the same time. A voter component compares their answers. Even if one node crashes or produces a wrong answer due to a hardware glitch, the majority of the other two nodes still produces the correct result instantly — the requester never sees any delay or error. This “triple modular redundancy” pattern is used in aircraft flight computers and spacecraft.

Both approaches survive failure — but the sequence of events inside the machine is very different, and that difference shows up as either a small user-visible blip or no blip at all.

6.1 How Failover Actually Happens (High Availability)

Let us trace through what happens, step by step, when a server in a highly available system fails:

The total time this takes — detection plus failover plus redirection — is what causes the small “blip” that high availability accepts as normal. Good systems get this down to a few seconds; excellent systems get it under a second.

6.2 How Fault Tolerance Avoids the Blip Entirely

Fault tolerance skips the “detection and failover” delay by never depending on a single active component in the first place. Instead of one server processing a request and a backup waiting to take over, multiple servers process the exact same request simultaneously, in real time, from the start. If one of them dies mid-processing, the others were already working on the identical task and simply continue — there was never a moment where “nobody was doing the work.”

This requires the systems to stay in perfect synchronisation, which is expensive. Every piece of state (memory, in-progress calculations, data writes) has to be mirrored instantly across all redundant nodes. This is why fault-tolerant systems are usually reserved for the most safety-critical or financially-critical parts of a system, rather than the entire application.

6.3 A Simple Java Example: Health Check for Failover

Below is a simplified Java example showing how a basic health-check-driven failover mechanism works. This is the kind of logic that sits inside load balancers and orchestration tools.

public class HealthCheckMonitor {

    private final List<ServerNode> servers;
    private final int timeoutMillis    = 3000;
    private final int failureThreshold = 3;

    public HealthCheckMonitor(List<ServerNode> servers) {
        this.servers = servers;
    }

    // Runs periodically, e.g. every 5 seconds via a scheduler
    public void runHealthChecks() {
        for (ServerNode server : servers) {
            boolean healthy = pingServer(server);
            if (!healthy) {
                server.incrementFailureCount();
                if (server.getFailureCount() >= failureThreshold) {
                    markUnhealthyAndFailover(server);
                }
            } else {
                server.resetFailureCount();
            }
        }
    }

    private boolean pingServer(ServerNode server) {
        try {
            HttpResponse response = server.sendHealthPing(timeoutMillis);
            return response.getStatusCode() == 200;
        } catch (Exception e) {
            return false;
        }
    }

    private void markUnhealthyAndFailover(ServerNode server) {
        server.setStatus(ServerStatus.UNHEALTHY);
        loadBalancer.removeFromRotation(server);

        ServerNode standby = server.getStandbyReplica();
        if (standby != null) {
            standby.promoteToPrimary();
            loadBalancer.addToRotation(standby);
        }
        alertOnCallEngineer(server);
    }
}

Notice the key ideas here: the health check runs on a schedule, requires multiple consecutive failures before acting (to avoid overreacting to a single slow response), and automatically both removes the bad server and promotes a standby. This entire flow is what “high availability” looks like inside real infrastructure code.

Understanding how a single user request travels through a system helps show exactly where fault tolerance and high availability mechanisms kick in.

In this lifecycle, the user experiences a short delay while the system detects the failure of Server A and reroutes to Server B. This delay — even if it is only a second or two — is the defining signature of a high-availability design, not a fault-tolerant one.

Now compare this with a fault-tolerant lifecycle:

Here, both nodes started working at the same instant. When Node A fails, Node B has already produced a valid result, so the voter simply uses it — the user never experiences any wait at all. This is the essential lifecycle difference: high availability reacts after detecting failure, while fault tolerance was already prepared before the failure occurred.

7.1 Data Consistency During Failover

One subtle but critical point in the data lifecycle is what happens to in-flight data during a failure. If Server A had accepted a write but not yet replicated it to the database before crashing, that data could be lost during failover unless the system uses synchronous replication (waiting for the backup to confirm before acknowledging the write to the user). This is a core trade-off: synchronous replication is safer but slower; asynchronous replication is faster but risks small data loss during a crash. Fault-tolerant systems almost always use synchronous, real-time state sharing to avoid this problem entirely, while many highly-available systems accept a small risk of losing the last few in-flight operations in exchange for better everyday performance.

Every architectural choice is a bargain. Here is the honest ledger for each approach, side by side.

8.1 Fault Tolerance

8.2 High Availability

Fault tolerance and high availability both interact heavily with how a system performs under load and how it scales as usage grows.

9.1 Performance Impact of Fault Tolerance

Because fault-tolerant systems run multiple copies of the same computation simultaneously and often require synchronous agreement between nodes (the “voting” step we saw earlier), they naturally add latency and consume more compute resources than a single-node system. A payment authorisation system built with triple redundancy, for example, will always be a little slower than a single-server version, because it has to wait for multiple nodes to agree before responding. This cost is accepted because the alternative — a wrong or missing payment authorisation — is worse.

9.2 Performance Impact of High Availability

High availability generally has a lighter performance cost during normal operation, since only one server (or a small active set) handles requests at a time, with standbys sitting idle or handling a smaller share of traffic. The performance cost mostly appears during the failover window itself — the few seconds where requests may be retried, queued, or slightly delayed while the system reroutes.

9.3 Scalability

High availability scales very naturally with horizontal scaling: simply add more servers behind the load balancer, and both capacity and resilience improve together. Fault tolerance is harder to scale horizontally because every additional redundant node adds coordination overhead — more nodes means more communication needed to keep them all synchronised, which can eventually become the bottleneck itself. This is why fault-tolerant designs are usually kept small and focused (e.g., 3 nodes voting) rather than scaled to hundreds of nodes the way stateless, highly-available web servers often are.

Redundancy, which powers both fault tolerance and high availability, is a double-edged sword from a security perspective. On one hand, redundant systems protect against certain attacks; on the other, they widen the “attack surface” — the total number of components an attacker could try to break into.

10.1 Security Benefits

• Resilience against Denial-of-Service (DoS) attacks: a highly available system spread across many servers and regions can absorb a flood of malicious traffic much better than a single server, because load balancers can distribute or block bad traffic before it overwhelms any one machine.
• Data integrity through redundancy: if an attacker corrupts data on one node, a fault-tolerant system’s voting mechanism can detect the mismatch and reject the corrupted result, protecting against certain classes of tampering.

10.2 Security Risks to Watch

• More servers to patch and secure: every redundant node is a potential entry point for an attacker, so security patching has to be applied consistently across every replica, not just one server.
• Replication channels can be attacked: the network links used to keep fault-tolerant nodes synchronised in real time must themselves be encrypted and authenticated, or an attacker could inject false data into the replication stream.
• Failover misuse: attackers sometimes deliberately try to trigger failovers (for example, by overwhelming a health check endpoint) to force a system into a less-tested standby path, hoping to find weaker security controls there.

You cannot manage what you do not measure. Both fault tolerance and high availability depend heavily on strong observability — the ability to see what is happening inside a system in real time.

11.1 Key Metrics to Track

• Uptime percentage: the core measurement of high availability, usually tracked monthly and annually against an SLA target.
• Mean Time Between Failures (MTBF): the average time a component runs before it fails — a higher MTBF means more reliable hardware or software.
• Mean Time To Recovery (MTTR): the average time it takes to detect and fix a failure — a lower MTTR means faster, more automated failover.
• Error rate and latency percentiles (p50, p95, p99): help detect when a system is degrading before it fully fails.
• Replication lag: for fault-tolerant and highly-available databases, this measures how far behind a standby copy is from the primary — high lag means higher risk of data loss during failover.

11.2 Logging & Alerting

Every failover event, every health check failure, and every redundant-node disagreement should be logged with a precise timestamp and root cause where possible. Centralised logging tools (such as the ELK stack — Elasticsearch, Logstash, Kibana — or cloud-native options like AWS CloudWatch Logs) allow engineers to reconstruct exactly what happened during an incident. Alerting systems should notify on-call engineers immediately when MTTR targets are at risk of being breached, ideally before customers even notice a problem.

Modern cloud platforms — AWS, Google Cloud, Microsoft Azure — have made both fault tolerance and high availability far more accessible than they were 20 years ago, when companies had to buy and wire their own redundant hardware.

12.1 High Availability in the Cloud

• Availability Zones (AZs): cloud providers offer multiple physically separate data centres within a region. Deploying servers across two or three AZs means a power outage or network failure in one AZ does not take down the whole application.
• Auto Scaling Groups: automatically detect and replace unhealthy server instances, and add more instances when traffic increases.
• Managed Load Balancers: services like AWS Elastic Load Balancer or Google Cloud Load Balancing come with built-in health checks and automatic traffic rerouting.
• Multi-Region Deployment: for the highest levels of availability, entire application stacks are duplicated across geographically distant regions (for example, Mumbai and Singapore), protecting against region-wide disasters.

12.2 Fault Tolerance in the Cloud

True fault tolerance in the cloud typically requires specialised managed services rather than generic virtual machines. For example, cloud databases like AWS Aurora Multi-AZ or Google Cloud Spanner are engineered to keep writing data correctly with essentially zero interruption even if an entire data centre fails, by using synchronous replication and consensus protocols under the hood. Building true fault tolerance yourself, from scratch, on plain virtual machines is possible but extremely difficult — most companies rely on these managed, purpose-built services instead.

This layered approach — multiple servers within an availability zone, multiple zones within a region, and multiple regions worldwide — is how large-scale cloud applications achieve very high availability numbers, often reaching 99.99% or better.

12.3 Blue-Green and Canary Deployments

Deployment strategy also affects availability. A blue-green deployment keeps two identical production environments; new code is deployed to the idle one (“green”) and traffic is switched over only after it is confirmed healthy, so a bad deployment never causes downtime — it just gets rolled back by switching traffic back to “blue.” A canary deployment sends new code to just a small percentage of users first, watching closely for errors before rolling it out to everyone, limiting the blast radius of any deployment-related failure.

12.4 Disaster Recovery and Backups

Disaster recovery (DR) is closely related to high availability but focuses specifically on recovering from large-scale, catastrophic events — an entire data centre burning down, a major regional power grid failure, or a natural disaster — rather than the routine, small-scale failure of a single server. Two numbers matter most in disaster recovery planning:

• Recovery Point Objective (RPO): how much data, measured in time, can the business afford to lose? An RPO of 5 minutes means backups or replication must happen at least every 5 minutes, so that in the worst case, only 5 minutes of data is lost.
• Recovery Time Objective (RTO): how long can the business tolerate being completely down before the disaster recovery process fully restores service? An RTO of 1 hour means the entire system, in the worst case, must be back up and running within an hour of a disaster being declared.

Regular backups, tested restore procedures, and a documented, rehearsed disaster recovery runbook are just as important as the live redundancy techniques discussed earlier — because even the most fault-tolerant, highly-available system can still be brought down by an event large enough to affect every redundant copy at once, unless those copies are spread across truly independent locations.

Databases sit at the heart of both fault tolerance and high availability, because losing data is often worse than losing a few seconds of uptime.

13.1 Database Replication Strategies

• Synchronous replication: a write is only confirmed to the user after it has been copied to at least one standby database. This guarantees no data loss during failover, at the cost of slightly higher write latency — the pattern typically used for fault tolerance.
• Asynchronous replication: a write is confirmed immediately, and copied to standbys shortly after. This is faster for everyday use but risks losing the last few writes if the primary crashes before replication completes — a common trade-off accepted in high-availability designs.
• Read replicas: extra database copies used only for reading data (not writing), which both improve performance by spreading out read traffic and provide additional standby copies that can be promoted during a failure.

13.2 A Java Example: Retry With Exponential Backoff (a High Availability Pattern)

When a database failover is happening, client applications often need to retry failed requests intelligently rather than giving up immediately or hammering the database with instant retries.

public class RetryWithBackoff {

    private static final int  MAX_RETRIES   = 5;
    private static final long BASE_DELAY_MS = 200;

    public String executeWithRetry(DatabaseCall call) throws Exception {
        int attempt = 0;
        while (true) {
            try {
                return call.execute();
            } catch (TransientDatabaseException e) {
                attempt++;
                if (attempt >= MAX_RETRIES) {
                    throw e; // give up, bubble up the failure
                }
                long delay  = BASE_DELAY_MS * (long) Math.pow(2, attempt);
                long jitter = (long) (Math.random() * 100);
                Thread.sleep(delay + jitter);
            }
        }
    }
}

Exponential backoff means each retry waits longer than the last (200 ms, 400 ms, 800 ms, and so on), giving the database failover process time to complete instead of overwhelming a struggling system with immediate retries. The random “jitter” prevents thousands of clients from all retrying at the exact same moment and causing a new traffic spike right as the system is recovering.

13.3 Caching for Availability

Caches (like Redis or Memcached) can serve stale-but-acceptable data during a brief database outage, effectively buying time for failover to complete without the user noticing a complete failure. This pattern, sometimes called “graceful degradation,” trades perfect freshness of data for continued availability — a good example of high availability’s philosophy of “keep something working” versus fault tolerance’s philosophy of “nothing should ever visibly break.”

13.4 Load Balancing Algorithms

In a microservices architecture, dozens or even hundreds of small independent services call each other constantly. A failure in just one small service can cascade and take down the entire application if not handled carefully — this is exactly where fault tolerance and high availability patterns become essential at the API level.

14.1 The Circuit Breaker Pattern

A circuit breaker prevents one failing service from dragging down every service that depends on it. It works much like an electrical circuit breaker in your house: if too much current (too many failures) flows through, the breaker “trips” and stops sending requests to the failing service for a while, giving it time to recover, instead of letting every caller wait on a timeout repeatedly.

public class CircuitBreaker {

    private enum State { CLOSED, OPEN, HALF_OPEN }

    private State state              = State.CLOSED;
    private int   failureCount       = 0;
    private final int  failureThreshold = 5;
    private long  lastFailureTime    = 0;
    private final long openTimeoutMs = 10000; // wait 10s before trying again

    public String callService(ServiceCall call) throws Exception {
        if (state == State.OPEN) {
            if (System.currentTimeMillis() - lastFailureTime > openTimeoutMs) {
                state = State.HALF_OPEN; // allow a trial request
            } else {
                throw new ServiceUnavailableException("Circuit is open, failing fast");
            }
        }

        try {
            String result = call.execute();
            reset(); // success, go back to normal
            return result;
        } catch (Exception e) {
            recordFailure();
            throw e;
        }
    }

    private void recordFailure() {
        failureCount++;
        lastFailureTime = System.currentTimeMillis();
        if (failureCount >= failureThreshold) {
            state = State.OPEN;
        }
    }

    private void reset() {
        failureCount = 0;
        state = State.CLOSED;
    }
}

Notice the three states: CLOSED (normal operation), OPEN (failing fast, not even trying to call the broken service), and HALF_OPEN (cautiously testing if the service has recovered). This pattern protects the overall system’s availability by containing the blast radius of a single failing dependency, rather than letting failures cascade upstream.

14.2 Bulkheads

Named after the watertight compartments in a ship’s hull that stop one flooded section from sinking the whole ship, the bulkhead pattern isolates resources (like thread pools or connection pools) per dependency, so if one downstream service is slow or failing, it cannot exhaust all the resources needed to serve requests to other, healthy services.

14.3 Idempotent APIs Support Safe Retries

An idempotent API is one where calling it multiple times with the same input produces the same result as calling it once — for example, “set my account balance to 500” is idempotent, but “add 500 to my balance” is not, because retrying it twice would incorrectly add 1000. Idempotency is essential for high availability because it makes retries (like the exponential backoff example earlier) safe, even if a request is accidentally sent twice during a failover.

A small set of patterns keeps showing up in resilient systems — and a corresponding set of anti-patterns keeps showing up in the post-mortems of systems that turned out not to be.

15.1 Useful Patterns in Detail

• Active-Passive Failover: one active node handles traffic; a passive standby takes over on failure. Simple, moderate cost, classic high-availability pattern.
• Active-Active Clustering: multiple nodes handle traffic simultaneously, sharing load and providing both scalability and resilience at once.
• N+1 Redundancy: if a system needs N servers to handle normal load, you run N+1, so that even after one server fails, you still have exactly enough capacity to handle full load.
• Graceful Degradation: when part of a system fails, non-critical features are turned off automatically so the core function keeps working (for example, an e-commerce site might disable “recommended products” during high load but keep checkout working).
• Chaos Engineering: deliberately injecting failures into a production or production-like system (pioneered by Netflix’s “Chaos Monkey”) to prove that fault tolerance and high availability mechanisms actually work before a real failure tests them for you.

15.2 Anti-patterns in Detail

• Single Point of Failure (SPOF): any component that, if it fails, brings down the entire system. Even one un-redundant load balancer or one un-replicated database can silently undo all the redundancy you built elsewhere.
• Untested Failover: having a standby server that has never actually been tested with a real failover drill. Many outages happen specifically because the “backup” system, when finally needed, turns out to be broken or out of date.
• Split-Brain: a dangerous situation where a network partition causes two nodes to both believe they are the “primary” at the same time, leading to conflicting writes and data corruption. Proper consensus protocols (like Raft or Paxos) are used to prevent this.
• Retry Storms: when many clients retry failed requests simultaneously without backoff or jitter, actually causing more load on an already struggling system and making the outage worse.
• Ignoring the “thundering herd” on recovery: when a failed service comes back online, all the requests that were queued or waiting can hit it at once, immediately overwhelming it again unless traffic is ramped back up gradually.

A short set of habits that, held consistently, prevent more incidents than any single clever fix ever will — and the mirror-image set of mistakes that keep showing up in post-mortems.

16.1 Best Practices

• Match the technique to the actual risk. Do not build expensive fault tolerance for a component where a 2-second blip genuinely does not matter. Save that investment for the truly critical path.
• Automate failover completely. If failover requires a human to wake up, log in, and run a script, your real recovery time is measured in tens of minutes, not seconds — no matter what your architecture diagram promises.
• Test failure regularly, not just once. Systems and teams change over time; a failover process that worked a year ago may silently be broken today unless it is tested (ideally automatically, ideally in production) on a regular schedule.
• Track your actual uptime and MTTR against your promised SLA. If you do not measure it honestly, you cannot know if your redundancy investment is working.
• Design for idempotency across your APIs so that retries during failover never cause duplicate or conflicting effects.
• Document and rehearse incident response, so that when something does break in a way automation did not fully handle, humans can respond quickly and correctly under pressure.

16.2 Common Mistakes

• Confusing “we have a backup server” with “we have high availability.” A backup that is not automatically detected and switched to within seconds does not meet most real-world availability targets.
• Forgetting the database. Teams often make their application servers highly available but leave a single, un-replicated database as a silent single point of failure.
• Over-engineering everything as fault tolerant. This wastes budget and adds unnecessary complexity to parts of the system that would have been perfectly fine with simpler, cheaper high-availability techniques.
• Not accounting for correlated failures. If both your primary and standby run in the same data centre, a single power outage takes both down together — redundancy only helps against failures that are truly independent.
• Skipping chaos testing. Many teams discover their failover does not work only during a real, high-stakes outage, rather than during a controlled test.

Theory becomes concrete when you see how the biggest companies in the world actually apply it. The examples below range from “high availability everywhere” to “true fault tolerance for the life-critical bits.”

17.7 Stock Exchanges

Stock exchanges like the NYSE or NSE (National Stock Exchange of India) process a huge volume of trades every second, where even a fraction-of-a-second discrepancy can mean incorrect prices being shown to traders, potentially causing massive financial losses or regulatory violations. These systems typically use hardware-level redundancy, dedicated low-latency networks with multiple physical paths, and fault-tolerant matching engines that keep order books consistent even during a hardware failure, because the cost of even a brief visible glitch in a live market is simply too high to accept.

Before jumping into the frequently asked questions, it is worth pausing on one more practical point: choosing between fault tolerance and high availability is rarely a one-time decision made at the start of a project. As a system grows — more users, more revenue riding on it, more regulatory scrutiny — the acceptable level of risk usually shrinks, and components that were once “fine with a two-second blip” may need to be upgraded toward stronger, more fault-tolerant designs. A good architect revisits this decision periodically, using real incident data and business impact numbers rather than gut feeling, to decide where the next investment in resilience should go.

Is a system that is fault tolerant automatically highly available?

Usually yes — since fault tolerance guarantees zero visible interruption, uptime will naturally be extremely high. But the reverse is not true: a highly available system is not automatically fault tolerant, because it may still have brief, visible interruptions during failover.

Which one costs more to build?

Fault tolerance is almost always more expensive, because it requires real-time synchronised redundancy across every critical component, rather than a standby that only activates after a failure is detected.

Can a system be both, for different parts?

Yes, and this is actually the most common real-world design. A payment core might be fault tolerant, while the surrounding product catalogue and recommendation services are simply highly available. Matching the technique to the actual criticality of each component is a hallmark of good architecture.

Does “99.999% availability” mean the system is fault tolerant?

Not necessarily. It means the total downtime over a year is very small (about 5 minutes), but there could still have been several brief, real interruptions during that year. Fault tolerance specifically means those interruptions should never have been visible at all, even for a moment.

What is the single most important first step for a team with no redundancy at all?

Eliminate the most dangerous single points of failure first — usually the database and the load balancer — since these tend to have the widest blast radius if they fail. Start with basic high availability (a second server, a load balancer, health checks) before considering full fault tolerance for any component.

Summary

Fault tolerance and high availability both exist to answer the same underlying question — “what happens when something breaks?” — but they answer it differently. Fault tolerance means the system keeps working with zero visible interruption, achieved through real-time, synchronised redundancy that is expensive and complex but essential for the most safety-critical or financially-critical components. High availability means the system stays up for the vast majority of the time, accepting brief, automated recovery windows measured in seconds, achieved through techniques like load balancing, health checks, and failover clusters that are far more cost-effective and widely applicable across everyday business applications.