Progressive Failure Modes

Any part of the system you are working on has a primary focus. It may also have secondary features.

In simple terms if you are selling books searching for a title and buying a specific book are the primary focus. Secondary features include sales counts, lists of reviews, you also may like details.

A component of a system has dependencies on sources of data. These are not always reliable. If you can still fullfil the primary focus it should be possible to present a stripped down version when the secondary features fail. Only if the primary feature of the component is failing should it report a direct error to the user.

This is similar to the concept of a mobile first progressive web app where basic features work in simple devices and additional options are layered on as screen size increases.

Building systems with this in mind will result in improved stability. Fancy add-ons should not compromise the basic functionality.

Thoughts on Rules Engines

Some years ago I built a rules engine system for my employer. This is the theoretical underpinning.

There are various types of rules that a rule engine can have. The most basic is the default. This will apply a value to an initialised but not updated field.

The next is a calculation. This will set a value typically based upon data in one or more locations. This will recalculate whenever either value changes.

Another is the non-limiting constraint. This will warn that a value is somehow incorrect but will not change values.

This contrasts with the limiting constraint that will prevent a value from violating it’s rules, enforcing a limit should the constraint be broken.