Synchronous vs. Asynchronous – A Lesson using Butter

There are two ways that information and requests get processed in your product: Synchronous and asynchronous.

Let’s explore what each of these terms means in real life, and the pluses and minuses of each approach. When we’re done, you’ll be able to talk with your developers about each of these methods and understand more fully how modern applications work under the hood.

Let’s say I’m preparing a piece of toast and I want to put some butter on it before I eat. Hang with me, I’ll bring it back to actual computer stuff at the end.

How It Works

In synchronous processing, your application gets a request, does all of the work to process the request, and returns an answer right away (called a response in programming-speak). If you and I were having a conversation, it would look something like this:

Me: “Can you please pass the butter?”
You: “Let me see if I have butter. Yep I have butter. Here’s the butter.”

In asynchronous processing, your application gets a request and agrees to return an answer sometime later. Now, by later I mean most often milliseconds later, but still it’s later. If we were having an asynchronous conversation, it would look something like this:

Me: “Can you please pass the butter?”
You: “I’ve got to check and see I’ve got butter. I’ll get back to you in a jiff.”
You (sometime later, running up to me out of breath): “It turns out I have butter and here it is!”

Why It Matters

With synchronous processing I’m waiting around for you to hand me the butter. If you have to rummage around in the refrigerator, unwrap a new stick, and put it in the butter dish before you hand it to me, then I probably get a little impatient.

If there are other people behind me in line who also want butter, they start to get really irritated that you’re taking so long to give me butter.

With asynchronous processing, I can ask you for the butter and go back to whatever I was doing knowing that you’ll get me the butter as soon as you can. I’m fine to wait a little longer because you didn’t keep me from doing other stuff. Most importantly, the other people who want butter can all ask you as well, knowing that you’ll get them their butter as soon as you can.

Just like with my simple example of asking for butter, with synchronous processing, your application is only as fast as its slowest component. If your application gets bogged down trying to service a request, performance suffers and users begin to despise you.

What’s Best?

Each processing method has its place. If you’re doing simple operations like looking up a user or logging a user into your application, synchronous processing is just fine. If, however, you are integrating with other applications or you have any doubt about how long it will take your application to service a request, you’re probably best served to use async processing.

The main downside to async processing is that it’s more complex to build. It’s also more difficult to handle when things go wrong. There’s extra development work to ensure that when things fail, they fail properly and in the right order.

Anymore, it’s much more common for an application to be heavily asynchronous because most of our applications talk to lots of other applications. As a result, the tools and languages to build asynchronous applications are getting better and better.

Just Remember

Both synchronous and asynchronous processing have their place. With synchronous processing, your users wait around for the answer to their request. With asynchronous processing, you give your users the answer when you’ve got it ready.

This is an over-simplification, to be sure, because we’re talking about such small units of time when it comes to computers, but those very small units of time add up quickly when there’s lots of requests to be answered.

Your Assignment

Can you think of examples of synchronous and asynchronous applications that you use every day? I’ll give you a few to start with:

• Email (asynchronous)
• Phone call (synchronous)
• In-person meeting (synchronous)
• Slack chat (asynchronous)

Now try and apply the concepts to things your application is doing. What should be asynchronous vs. synchronous? Remember, it’s not all or nothing.