Timeouts

Avoiding cracks

We have traveled through the vale of shadows. Now it is time to come into the light. In the last chapter, we saw the antipatterns to avoid. In this chapter, we’ll look at the flip side and examine some patterns that are the inverse of the killers from the last chapter. These healthy patterns provide the architecture and design guidance to reduce, eliminate, or mitigate the effects of cracks in the system. Not one of these will help our software pass QA, but they will help us get a full night’s sleep, or at least an uninterrupted dinner with our family, once our software launches.

Don’t make the mistake of assuming that a system that includes more of these patterns is superior to one with fewer of them. “Count of patterns applied” is never a good quality metric. Instead, let’s develop a recovery-oriented mind-set. But remember, expect failures. Apply these patterns wisely to reduce the damage done by an individual failure.

Timeouts

In the early days, networking issues affected only programmers working on low-level software: operating systems, network protocols, remote filesystems, and so on. Today, every system is a distributed system. Every application must grapple with the fundamental nature of networks: networks are fallible. The wire could be broken, some switch or router along the way could be broken, or the computer you are addressing could be broken.