A large amount of the resource consumption of software systems is driven by the need for synchronous communication between clients and servers. If transactions can be allowed to accumulate, even just a little bit, and then processed in batches, the overall efficiency of software can improve substantially. Asynchronous designs thus have the potential to help reduce the footprint of many software systems.

Unfortunately, many of our "intuitive" models of the world -- the very ontologies that underlie our ideas and actions -- assume a kind of synchronous interaction between things in the world. This synchronicity concept then spills into the designs of the systems we build, and the framing we use when approaching engineering problems. Asynchronous code seems "weird" compared to the "intuitive" synchronous interfaces that are typically taught first to novice programmers.

To the extent that we can shift our mindset towards asynchronous designs our software will become more efficient. That does not mean that one should use asynchronous communication in every scenario. An important skill in the development of asynchronous programs is to know when to use a synchronous approach. Some tools can help in the shift away from synchronous interffaces, including the Go programming language, which was designed with a very powerful yet pragmatic and simple concurrency model.