Configuring Caching and Queueing

The technologies the DCS uses for caching and communications can be changed through configuration.

The DCS has the following configurable components.

Component	Notes	Default	Examples of Alternatives
Cache	Caches the values of lookups and traces.	Redis	SQL Server
Queue	Sends requests to the backend (via dapr)	RabbitMQ	Azure Service Bus
Pubsub	Sends messages to subscribers (via dapr)	RabbitMQ	Azure Service Bus Redis
State	Stores state. Used for results, binary data storage and roadnetmanager state (via dapr)	Redis	Azure Storage

These pages describe how to configure them for development. For production see the Deployment Guide and the TS.Comms wiki

To use real (as opposed to emulated) azure resources you must configure secrets

• Configuring Secrets for Azure Connections

Configuring PubSub and Queueing

• [Configuring PubSub and Queueing via Azure Service Bus](configuring-pubsub-and -queueing-via-azure-service-bus.md)

Configuring State Storage

• Configuring State Storage via Azure Storage

• Configuring State Storage via Azurite

Configuring Cache

The DCS requires a configured cache for traces and distances.

We currently support caching with either Redis (the default) or SQL Serer.

Both implementations are based on IDistributedCache

The cache type is controlled by the CacheType setting in dev\docker-compose\.env

By default the cache type is set to Redis. If you want to use SQL Server see the link below.

• Caching with SQL Server

Optional: Removing Redis

If you switch the state to using Azure Storage and the Cache to using SQL Server you can remove the Redis dependency from your image:

• Delete dev\dapr\components\state.yml
• Delete the services:redis section in dev\docker-compose\docker-compose.yml
• Delete the redis dependency from the x-services:dapr-service:depends_on section in dev\docker-compose\docker-compose.yml
• Delete the redis entry from the volumes section in dev\docker-compose\docker-compose.yml