I think that the one of the most important habits of good design and engineering is end-to-end thinking. Solving problems is fine, but they need to be the right problems, and this means they need to be solutions all the way to the actual ends of the system.
Pat Helland writes this month about an even more funky, extreme version of this principle: Side-Effect-Thinking.
He focuses on digital transactions which are the backbone of the digital world.
The basic observation is that digital systems are composed of many pieces and layers which interact through APIs that are specifically designed to hide the TMI. These systems are also connected to real world systems, which may act in response to a transaction.
The main point is, of course,
“One system’s side effect is another’s meat and potatoes.” (, p. 39)
The whole idea of APIs is to hide how the system works. By design, we have no idea exactly what happens when we place an order, or change an order, or whatever. Lot’s of stuff goes on behind the scenes, and we neither know nor need to know about it.
Helland points out that a side-effect of this design strategy is that a transaction may have knock on effects much wider than we might guess. He describes a scenario of reserving a hotel room. This may trigger the hotel to increase staff for that period, to order additional supplies, reschedule maintenance, and so on. Suppliers may respond with new orders and reserve capacity. And so on. All I asked for is a room!
It becomes more interesting when you cancel the room request. In one sense, the transaction is reversed, and all effects undone—in the reservation systems. But the side effects are not and some cannot be undone.
“cancelled’ transactions don’t undo side effects“
He also points out that “idempotent” operations are idempotent only from the viewpoint of the transaction system. Each execution may produce the same result, but each will have side effects. If nothing else, the traffic will be logged (many times and at many levels of the system).
(Historic note: in the early days of the web, it wasn’t uncommon for web servers to swamp their logging and other ‘hidden’ systems, even when there was only a few pages that never changed. The information delivered was trivial, all the work was side effects.)
As I said, all this stems from the completely sound and reasonable design principle of information hiding. It would be impossible to build distributed systems any other way. On the other hand, designers implementing the system would do well to think about side effects that the callers might cause.
I would note that side-effects like those described by Helland have been the source of break-ins and denial of service attacks. Any of the scenarios in the article could, if repeated many times, become a denial of service attack. Some of them would be weird and unprecedented attacks, such as creating local petrol shortages by spamming hotel reservation systems.
Side effects and their ramifications will be even more problematic as the Internet of Things deploys. I don’t really know what the IoT will actually be, but most visions of it imagine that everyday actions will trigger waves of automatic transactions among the “Things”, which will also cause real world actions. TMI to the TMth power!
Following the spirit of Helland’s scenarios, imagine that when you cancel your hotel reservation (triggering mischief in France and memory fragmentation in some database), your home infers that you will be home that day instead of away. The “smart home” had planned to stand down many systems and conduct maintenance, but now anticipating what you will need, and proactively purchases extra electricity and utilities, cancels a maintenance visit, and orders food. These orders in turn trigger a wave of transactions and just-in-time orders by the services. And so on.
If this sounds like a chaotic system, it might very well be.
Remind again, me why the IoT is a good idea?
- Pat Helland, Side effects, front and center. Communications of the ACM, 60 (7):36-39, 2017. http://queue.acm.org/detail.cfm?id=3099561