Systems / programs / distributed algorithms / ... are often described with the predicate robust or fault-tolerant.

What is the difference?


When I google for +robust +"fault-tolerant", I only get two hits, both unhelpful.

When I googlescholar for the terms, I find a lot of papers that have both terms in their title. Unfortunately, they do not precisely define the terms :( But since they use both terms, it seems that neither implies the other.


2 Answers 2


Both describe the consistency of an application's behavior, but "robustness" describes an application's response to its input, while "fault-tolerance" describes an application's response to its environment.

An app is robust when it can work consistently with inconsistent data. For example: a maps application is robust when it can parse addresses in various formats with various misspellings and return a useful location. A music player is robust when it can continue decoding an MP3 after encountering a malformed frame. An image editor is robust when it can modify an image with embedded EXIF metadata it might not recognize -- especially if it can make changes to the image without wrecking the EXIF data.

An app is fault-tolerant when it can work consistently in an inconsistent environment. A database application is fault-tolerant when it can access an alternate shard when the primary is unavailable. A web application is fault-tolerant when it can continue handling requests from cache even when an API host is unreachable. A storage subsystem is fault-tolerant when it can return results calculated from parity when a disk member is offline.

In both cases, the application is expected to remain stable, behave uniformly, preserve data integrity, and deliver useful results even when an error is encountered. But when evaluating robustness, you may find criteria involving data, while when evaluating fault-tolerance, you'll find criteria involving uptime.

One doesn't necessarily lead to the other. A mobile voice-recognition app can be very robust, providing an uncanny ability to recognize speech consistently in a variety of regional accents with huge amounts of background noise. But if it's useless without a fast cellular data connection, it's not very fault-tolerant. Similarly, a web publishing application can be immensely fault-tolerant, with multiple redundancies at every level, capable of losing whole data centers without failing, but if it drops a user table and crashes the first time someone registers with an apostrophe in their last name, it's not robust at all.

If you're looking for scholarly literature to help describe the distinction, you might look in specific domains that make use of software, rather than broadly software in general. Distributed applications research might be fertile ground for fault-tolerance criteria, and Google has published some of their research that might be relevant. Data modeling research likely addresses questions of robustness, as scientists are particularly interested in the properties of robustness that yield reproducible results. You can probably find papers describing statistical applications that might be helpful, as in climate modeling, RF propagation modeling, or genome sequencing. You'll also find engineers discussing "robust design" in things like control systems.

The Google File System whitepaper describes their approach to fault-tolerance problems, which generally involves the assumptions that component failures are routine and so the application must adapt to them:

This project for a class at Rutgers supports a "component-failure" oriented definition of "fault tolerance":

There are loads of papers on "robust modeling XYZ", depending on the field you investigate. Most will describe their criteria for "robust" in the abstract, and you'll find it all has to do with how the model deals with input.

This brief from a NASA climate scientist describes robustness as a criteria for evaluating climate models:

This paper from an MIT researcher examines wireless protocol applications, a domain in which fault-tolerance and robustness overlap, but the authors use "robust" to describe applications, protocols, and algorithms, while they use "fault-tolerance" in reference to topology and components:


I really like @johnnyb's answer and endorse it for its crisp definitions. But having worked in the field for a few decades, I recognize another (much less formal and precise) way that these terms are frequently used:

As informal points along a continuum from "unreliable" to "perfectly reliable."

There is no system, application, or service that can guarantee it will always and forever be at work ("continuously available" or "permanently available"). "Fault tolerant" has long been a stand-in for "we've done everything humanly possible with current technology to make sure this thing keeps running properly."

Words like "robust," "hardened," and "highly available" are used as softer milestones toward that goal of continuous operation. They reflect increasing levels of effort, investment, and confidence.

Because these terms are informally used, there is no entirely canonical ordering. "Highly available" is usually a strong claim, just under "fault resilient" or "fault tolerant." But is "hardened" better than "robust"? Or vice versa? It depends on the context. These are also frequently used as product marketing claims, with all the boasting and intentional imprecision that entails.

Usually organizations working toward these goals have their own internally agreed-upon progression, usually at least roughly linked to project goals/deliverables and external metrics such as "three nines" or "six nines."

@johnnyb also touches on a critical distinction: The difference between platform up/down status (availability) on one hand, and algorithm, application, or service attributes on the other.

I say "attributes" because there are many: performance, correctness, and imperturbability are just a few key ones. Is a system meaningfully available and correct if it's operating at just 10% of rated performance? Not according to business owners if it's the busy season! There's no great virtue in a system that truly never goes down, yet that also gives incorrect answers much of the time. Finally, is a data analytics system running "right" if a 0.2% variation in input gives a 3,400% different answer? Perhaps...but it's going to seem a rather capricious and unsatisfying model to many. I won't go through the extended list of attributes, but data integrity, data safety, data privacy, and other issues of correctness and security are common concerns. (If you're a very large organization or government agency, you increasingly worry about preserving those attributes not just over a few years or product cycles, but over spans of decades or possibly even centuries. There are as yet no proven architectures, processes, or approaches to accomplish this.)

These possible variances between "up and running" and "doing what we want"--and how to specify, measure, and prevent such variances--have long been a challenge, even once the redundancy, hardening, and other steps toward fault-tolerance have been taken. And in informal usage, "running" and various forms of "running like I want it to" are conflated, without all the clear distinctions one would want.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.