7 Components for messaging and caching

The chapter explains how distributed applications rely on asynchronous communication and shared infrastructure to stay responsive and scalable. It begins with message brokers, showing how queues let one service publish work while another consumes it later, which keeps user-facing requests fast even when additional processing must happen in the background. It also distinguishes between queue-style processing, where a message is handled once, and topic-style processing, where multiple subscribers can receive the same message.

Using Aspire, the text demonstrates this idea with RabbitMQ and Azure Queue Storage. An order-placement flow is built so that a customer can submit an order, the API records it in the database, and a message is published for a background service to react to later. The consumer updates delivery tracking after receiving the message, and the examples show how Aspire wires up the broker, how queues are declared and used, and how the same general pattern can be implemented with different messaging technologies.

The chapter then shifts to distributed caching and locking with Redis. Caching is used to avoid repeated database reads by storing frequently requested product data in shared memory, while distributed locks prevent multiple threads or services from modifying the same resource at the same time. The examples show how to register Redis in Aspire, use it both as a cache and as a locking mechanism, and manage the stored data through Redis Commander, reinforcing the broader lesson that shared infrastructure can improve both performance and correctness in distributed systems.

Message-broker workflows

Triggering an order-tracking service when an order is placed

Multiple applications accessing the same distributed cache

Distributed locking controls which applications can access a database resource.

Redis Commander endpoint in the Aspire dashboard

Redis Commander interface

• Message brokers transfer data between applications and services via message queues. Although message-broker technologies are built differently, their underlying operational principles are similar.
• Aspire supports a wide variety of message-broker integrations:
• RabbitMQ is a popular technology-agnostic message broker that is highly configurable.
• Azure Queue Storage, as the name suggests, is specific to Azure and is part of an Azure Storage account.
• Azure Queue Storage may be preferable to RabbitMQ in some situations because it’s significantly easier to set up and work with, though it loses some of RabbitMQ’s flexibility.
• A cache is an in-memory data store from which data can be retrieved more quickly than from a database. Caching is useful for storing data temporarily so that it can be retrieved faster, which results in better user experience.
• A distributed cache is an in-memory data store that multiple services on the network can access.
• A distributed lock can be implemented with a caching mechanism and shared among services to ensure that only one thread at a time can access a resource. Locking functionality is useful while particular data is being updated because it ensures that no other processes try to update it.
• Aspire can host a Redis component, which can be used for both distributed caching and locking. It’s the same component that can be used for output caching, but the locking and distributed caching functionality use a different client library from the one used for output caching.
• Redis Commander is a tool that allows users to manage Redis directly. It can integrate with Aspire natively.

FAQ