Asynchronous communication is NOT a new concept.
Message queues have been a core component of distributed systems for many years.
Async comms is simply the same concept applied to distributed teams.
In a distributed system, messages are sent between each of its services.
Issues can occur whenever:
- One of the services is unavailable -> Messages get lost
- One of the services receives too many messages in a short period of time -> Fails to process some of them
A message queue architecture addresses these fragilities, and makes the distributed system:
- More Robust. Eg: Works with a node unavailable
- More Performant. Eg: Requests can be batch processed
- More scalable. Eg: Load balancers can make traffic spikes manageable
The distributed system in this example doesn't use message queues.
That means whenever Service B is unavailable:
- Service A doesn't get feedback for the messages sent to B
- Service C's output is degraded, as it depends on B
- Service B will have a cold restart
That's why message queues became such a popular pattern in distributed systems.
The publish-subscribe pattern means that a service can publish messages to other services.
And those messages get consumed at the subscriber's pace.
In the same example, if Service B is unavailable on a system that has message queues:
- All other services can still send messages to Service B, and those get stored in B's message queue.
- Service B will have a hot restart, with a batch of messages ready to process.
The same constraints exist in a distributed remote team:
- Team members can be unavailable, especially with time zones spread across the globe.
- Team members can receive more requests than they can handle.
- Tasks that require deep work shouldn't be constantly interrupted.
In this team composed of Mary, Oleg and Kumar, if their processes rely on synchronous communication, such as meetings or real-time feedback, then their workflow gets massively disrupted when Oleg becomes unavailable:
- Mary doesn't get feedback.
- Kumar lacks key input.
On the other hand, if their processes are mostly asynchronous, without the need for real-time feedback, then Oleg's absence won't impact the workflow much:
- Mary continues sending requests to Oleg, not expecting real-time feedback.
- Kumar works on the backlog until Oleg is back.
These are some reasons that could cause Oleg to be unavailable:
- Is on vacation or sick leave.
- Works from a different time zone, and is sleeping.
- Is on a meeting and can't reply now.
- Is working on a deep-focus task, and marked himself unavailable for a few hours.
Yes, Oleg can mark himself unavailable for a few hours to do deep work.
Given that new requests go to his "message queue" and don't require immediate attention.
He can produce higher-quality deep work tasks (by focusing on them), without creating blockers for his team.
This is an example set of tasks in the workflow of Mary, Oleg, and Kumar.
And why neither Mary nor Kumar becomes blocked by Oleg's unavailability.
Follow us for more knowledge about remote work
We'll be publishing new articles every week, and new social media content every day. If you enjoyed this article, follow us on Twitter or Linkedin, and stay in the loop. Share our content and drop us a comment there. Let's help more people learn about remote work.