Asynchrony

Tying in somewhat closely with the notion of resiliency and open communication is the concept of asynchronous communication. This is a hugely important concept for maintaining any semblance of reliable performance on a networked program. Put simply, it's the concept of processing the result of a request that is not provided by the code internal to your system when that result becomes available.

When your program needs to request some resources from another node on its network, there is a round-trip time associated with sending your initial request and then receiving some meaningful response. During that time, you program technically could lock and wait for the response to come back, but realistically, there is no reason why it should lock and wait. However, even after our program may have moved on, deciding not to wait on the response to our initial request, we typically want to take a step back and handle the response whenever it does come back over the network. This process is asynchronous programming, and it's a major key to developing reasonably performing network software.

One obvious case of asynchronous programming you may have encountered separately from the context of network programming is in programming responsive user interfaces (UI). Typically, a UI component needs to actively listen and respond to user inputs whenever that user chooses to engage with it. Since the programmer can't ever know precisely when a user might want to press a button they've been presented with, they must respond to the input at the earliest moment that resources that can respond to the input without keeping those resources on hold while they wait to respond.