> ## Content Index
> Fetch the complete content index at: https://insights.growthlogic.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Approaching Basic Scalability Problems Using Async Communication
- URL: https://insights.growthlogic.net/approaching-basic-scalability-problems-using-asynchronous-communication/
- Published: 2026-07-21T19:34:36.000Z
- Updated: 2026-09-15T16:25:48.000Z
- Author: Aleksandr Jones

We'll discuss a highly reusable architectural design pattern that addresses common problems in distributed cloud systems.

In distributed systems, as site traffic scales, the data storage layer often becomes a performance bottleneck. Even with optimization, saving data in an atomic database transaction remains resource-intensive.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-46.png)

For a single transaction, this is rarely a challenge. However, when multiple parties attempt to commit transactions simultaneously, resource contention can spike. Moreover, latency from the data tier can quickly propagate to other parts of the system, making it less responsive. 

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-47.png)

We could try to preemptively solve our performance problems by selecting an Azure SQL service tier with adequate CPU, RAM, and storage. However, there's no sense in making infrastructure decisions without data to back them up. For that, there's no better source than performance testing.

During performance testing, we send simulated traffic to a QA instance. We're trying to estimate infrastructure requirements while also addressing obvious flaws in our system's performance. Our testing feedback loop is disarmingly simple.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-24.png)

During testing, we're peppering the system with questions. Are these resources sufficient to meet our SLA? Does our database have the indexes needed to prevent table scans? Are we releasing in-memory objects for garbage collection? etc.

Assuming we arrive at a high-performance system, we still face a common problem: once data is persisted, other subsystems have no way to know about the transaction without making additional outbound calls.

Thus, we have the basic setup for introducing message queuing, an asynchronous communication pattern. We'll use Azure Service Bus as our reference point for designing the solution. It provides highly resilient, high-performance message queuing.

With message queuing, we can defer committing our records to a database transaction and avoid the immediate performance hit. Instead, we enqueue a request to our message queue.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-34.png)

A background worker, typically an Azure Function, then pulls (dequeues) our save request and executes the database transaction, persisting our data.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-48.png)

We've safely decoupled request handling from the persistence layer. Requests are queued immediately and persisted eventually at a controlled pace. That's the asynchronous part.

The most immediate benefit is improved performance. Queuing messages to Azure Service Bus is fast – typically single- to low-double-digit milliseconds. By comparison, database transactions spanning multiple tables can take ten times (10x) or longer to execute.

Now, let's expand our communication channel to serve multiple subsystems. Instead of queuing requests for a single consumer, we publish our message so that multiple systems can listen to it – this is also known as subscribing.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-36.png)

With the pub/sub pattern, we can communicate with a much larger audience than with a single, isolated system.

Messages are generally organized into topics, e.g., new orders, custom updates, commit order #233, and commit order #235\. Designing topics effectively is non-trivial and requires special attention, and we'll address it later.

Let's briefly review our asynchronous communication model, now with subscribers in each system's silo.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/07/image-49.png)

By introducing message queuing, we trade transaction latency for the blinding-fast speed of queuing. We have a shared communication channel, enabling loosely coupled, controllable connections. We can still safely execute database transactions at a controlled pace.

No doubt, this adds complexity. Moreover, managing ongoing operations will require additional thought. However, this approach is critical to defining the base infrastructure that enterprise platforms need to grow.

This is scalable and powerful, and it can adapt to shifting priorities. 

Several topics remain, including how to manage interfaces to provide users with a good experience when saving records. We also need to resolve some edge cases for handling exceptions that inevitably occur during message processing. Asynchronous processing offers better scalability, not perfection. 

Nevertheless, we have a solid foundation for guiding future projects toward success. I hope you found this discussion helpful.