---
title: "Redis | Skills We Assign For | Azendo"
description: "Redis as cache, lock and session store — eviction, persistence and the failure modes to plan for, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/redis/"
---

[Skills](https://azendo.co/skills/) Data stores and query 

# Redis.

Redis is an in-memory data store used as a cache, a session store, a rate limiter, a lock and a lightweight queue. Its speed comes from holding data in memory, which is also the source of its main design constraint: memory is finite, and eviction behaviour has to be chosen deliberately.

## Where Redis fits on a long engagement.

Redis is easy to add and easy to become quietly dependent on. A cache introduced to relieve the database becomes load-bearing once traffic grows around it, and at that point losing Redis is no longer a performance event, it is an outage. Knowing which of the two a given deployment is — a true cache or a de facto primary store — is the question worth answering early.

The recurring production issues are predictable. An eviction policy left at the default surprises people when memory fills, keys written without a TTL accumulate until they do, and cache invalidation logic accretes until nobody is confident what a given key means. None of these are hard problems; they are all consequences of decisions nobody made explicitly.

## What an assigned team does with Redis.

Caching correctness is one of the areas where continuity pays most visibly. Understanding which keys are safe to evict, and what stale data means for a given screen, is knowledge about the product rather than about Redis, and it does not transfer with a handover document.

That knowledge accumulating in the same people is the argument for a standing assignment rather than capacity booked per piece of work. What that commitment costs and how it is agreed is set out in [how the monthly fee is built](https://azendo.co/pricing/).

## What we use Redis for.

* Taking read load off the primary database Caching the expensive queries with deliberate TTLs and an invalidation path that is written down.
* Distributed locks and rate limiting Coordinating work across several instances without inventing a coordination mechanism in application code.
* Sessions that survive a deploy Session state outside the application process, so a rolling restart does not sign everybody out.

## How Redis capacity is assigned.

Redis work is assigned inside the discipline that owns the service using it. Where the constraint is the data layer itself rather than the application, that sits under [managed data services](https://azendo.co/services/data-engineering/).

## Roles we assign Redis for

* [Backend Developer Software development](https://azendo.co/services/software-development/backend-developer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in data stores and query

* [SQL — skill we assign for](https://azendo.co/skills/sql/)
* [PostgreSQL — skill we assign for](https://azendo.co/skills/postgresql/)
* [MySQL — skill we assign for](https://azendo.co/skills/mysql/)
* [MongoDB — skill we assign for](https://azendo.co/skills/mongodb/)
* [Snowflake — skill we assign for](https://azendo.co/skills/snowflake/)
* [BigQuery — skill we assign for](https://azendo.co/skills/bigquery/)
* [Prisma — skill we assign for](https://azendo.co/skills/prisma/)
* [Postgres — skill we assign for](https://azendo.co/skills/postgres/)

## Tell us what your roadmap needs Redis for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)