An architectural fundamental is that things that are not related should not cause failure on each others’ part. The printer breaking should not stop the processing of orders. It does stop the printing of orders (duh), but should not stop the processing.
Some of the systems I deal with put me in mind of a sewage system. Bear with me here…
So, imagine the following undesirable situation. You are standing at the sink after dinner washing the dishes/pots/pans etc. It had been raining very hard all day, so the drainage systems had been well overtaxed. You are startled to see stuff coming UP the drain (perhaps from your neighbors house – you can tell what they had for dinner too). This is clearly an undesirable effect.
On further analysis you realize that the drainage system couldn’t take the runoff fast enough, so your house, being lower than your neighbours, became the lowest point their effluent could reach. Oh dear.
Of course restuarant codes (at least in the USA) have a cure. They make sure there is a buffer zone between the sewage system and any sink where food is prepared. It is an airgap and a sufficiently large gap that any attempt by effluent to rise up will be nullified. It will spread all over the floor instead. Not much better, but definitely not contaminating food in a sink.
So what’s the lesson here? Denial of Service through increased load on a system is something to watch out for. make sure you understand the implications and design accordingly.
This is as important at a business level as it is at a technical level. Who hasn’t experienced a lack of planning – perhaps an airline offering a fare sale and not scaling enough to have call center representatives. Or the fiasco in Texas where the “business” (the State) offered rebates for trading in old appliances. They underestimated demand horribly.
The enterprise really has to understand its business models and take care to scale appropriately – and communicate that through to all interested and relevant parties