Hey, I’m Colin! I help PMs and business leaders improve their technical skills through real-world case studies. For more, check out my Live cohort course and subscribe on Substack.
Anyone working closely with engineering has probably heard the term “async” a few times. Let’s dive into what async means and talk about how it impacts discovery, UX, and engineering.
Sync vs Async
Synchronous processes are how most people think software works. When I click a button or submit a form, the application runs some processes and returns the result.
Let’s examine a simple example: adding 1+1.
Here’s what our synchronous process would look like:
Asynchronous processes are the opposite. They return the result some time in the future instead of returning an immediate result.
In the async example, we can see that the request was stored and processed later. Once we had a result, we notified the user.
Entire systems can be designed to work asynchronously, or just small sections of code.
If you’ve ever submitted a report request, waited for an Uber, or received an email after applying for a job, you’ve taken part in a async process.
Example #1: Uber - Ride Matching
I love using Uber when traveling. As I walk through the terminal, I just pop the app open, request a ride, and get directions to exactly where I need to get picked up.
Like me, you’ve probably used Uber countless times without thinking about how it works. Turns out, it leverages an asynchronous process.
When a driver signals they’re ready to go, Uber acknowledges the requests and puts them in a queue. They match drivers to riders based on a First-In First-Out ordering (more here). Once matched, both the driver and the rider are notified.
What happens if the rider cancels the ride? We can just put the driver back into the queue and they’ll get another request.
Another benefit of this system is that it gracefully handles capacity constraints. If we have more ride requests than drivers, the ride requests can sit in the queue until a driver is ready to pick up.
Example #2: Stripe - Report Generation
Next up is Stripe. It's pretty common for business owners to export Stripe data and perform analysis in another application like Excel or Salesforce.
Here’s how that system works:
Reporting is a common use case for asynchronous processes, as each report can take minutes to run. Rather than overwhelming our reporting servers, we can queue the requests and work them in order, then notify our users when the job is complete.
Example #3: Job Applications
Unfortunately for many of us, job applications may be the most common example of an asynchronous process you’ve interacted with. You’ve likely seen something like this dreaded email before:
Behind the scenes, here’s what’s happening:
Why it Matters
Asynchronous processes are extremely common. They are typically used in two scenarios:
The workflow requires some human interaction or a long running process
We expect a large number of requests and need to handle scaling gracefully
Like in the examples above, there are workflows that simply fit better with asynchronous processes. Trying to fit a job review process into a real-time workflow would cause enormous headaches for HR teams trying to respond fast enough.
The other common case is in applications at scale, especially in a microservices architecture. Each component of our backend may process requests at different speeds, so asynchronous processing ensures everything gets done eventually. Often the alternative is overwhelming our servers and crashing our applications.
Being able to spot asynchronous processes also makes you a better PM. You can ask customer questions during discovery like “How would you want to be notified when it’s ready?”, you can partner better with UX by guiding discussion on how users will get updates, and you can give engineering better requirements by suggesting the process should be queued.
Next time you’re working on a feature, ask yourself - “Is this a synchronous or asynchronous process?”. You might be surprised by the answer!