Skip to content

Conversation

@helenktsai
Copy link
Member

@helenktsai helenktsai commented Oct 28, 2025

  • Removed/replaced references that are not specific to the concept of single vs multiple storage accounts
    • queue limits
    • Scale Units
  • Simplified explanation of scaling out
  • Updated code example of registering endpoints to more explicitly indicate aliases are being used since the importance of aliases is explained above

helenktsai and others added 9 commits October 28, 2025 13:34
Clarified throttling issues related to Azure Storage Queues and the use of multiple storage accounts.
Clarified language regarding scaling out to multiple storage accounts and throughput limitations.
Removed redundant text and clarified guidance on using multiple storage accounts with Azure Storage Queues.
Restored the Scale Units section with detailed explanations about throughput limitations and resource partitioning.
Added note about throughput limits and scaling strategy.
Updated the section on routing with multiple storage accounts to clarify the use of NServiceBus and the notation for specifying destination addresses.
@ngallegos ngallegos marked this pull request as ready for review November 3, 2025 21:48
Revised wording for clarity and consistency in the documentation regarding endpoint registration and message routing.
Comment on lines 54 to 63
### Using registered endpoints

An example of a partitioned application with a different number of deployed scale units is an application deployed in various regions.
In order to route a message to an endpoint without having to specify the destination each time, the endpoint can be registered for a given command type, assembly, or namespace.

![Scale units](azure04.png "width=500")
snippet: storage_account_routing_registered_endpoint

> [!NOTE]
> Use real Azure storage accounts. Do not use Azure storage emulator as it only supports a single fixed account named devstoreaccount1.".
Once the endpoint is registered, no send options need to be specified.

snippet: storage_account_routing_send_registered_endpoint

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should move this above so it immediately follows the connection string aliases as the first example showing and introducing the @ notation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 44 to 46
Aliases can be provided for both the endpoint's connection strings as well as other accounts' connection strings. This enables using the `@` notation for destination addresses like `queue_name@accountAlias`.

snippet: storage_account_routing_send_options_alias
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should remove this lower, perhaps to the end of the configuration section in this article, since this is the "exceptional" scenario for customers. Most of the time they should be using routing configuration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I addressed this?

Comment on lines 70 to 74
### Publishers

NServiceBus allows to specify destination addresses using an `"endpoint@physicallocation"` when messages are dispatched, in various places such as the [Send](/nservicebus/messaging/send-a-message.md) and [Routing](/nservicebus/messaging/routing.md) API or the `MessageEndpointMappings`. In this notation the `physicallocation` section represents the location where the endpoint's infrastructure is hosted, such as a storage account.
Similar to sending to an endpoint, the transport can also be configured to subscribe to events published by endpoints in another storage account, using:

Using this notation it is possible to route messages to any endpoint hosted in any storage account.
snippet: storage_account_routing_registered_publisher
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make this section follow immediately after the routing configuration.

Comment on lines 64 to 66
### Using send options

Although registering endpoints to route messages is preferred, NServiceBus allows specifying destination addresses using the `<endpoint>@<physicallocation>` notation when messages are dispatched. Using this notation, it is possible to route messages to any endpoint hosted in any storage account. The `physicallocation` element represents the location where the endpoint's infrastructure is hosted, such as a storage account alias.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be the last section. I am wondering if we should show both the SendOptions and the short context.Send("endpoint@account") form.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean "Using send options" should go below the "Publishers" section? I don't have an opinion on whether or not to show both.

> Use real Azure storage accounts. Do not use Azure storage emulator as it only supports a single fixed account named "devstoreaccount1".
> [!NOTE]
> There are limits to how much using multiple storage accounts increase throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> There are limits to how much using multiple storage accounts increase throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs.
> There are limits to how much increasing storage accounts increases throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants