Challenge
Popular keys expire together and every request hits the database.
Agnotic approach
Expiry times get random jitter, and one request rebuilds a missing key while others wait or serve the old value.
Redis Development
Redis development, caching and consulting
Redis is easy to add and easy to misuse: a cache that becomes the only copy of the data, a queue that loses jobs on restart, a hot key that stalls every request. Agnotic Technologies designs and builds the Redis layer of your application and picks the structure, persistence, eviction and hosting for each job it does.
Structure per workloadPersistence and eviction by designHigh availabilityAccess control and TLS
Trusted by global innovators
Redis
What does Redis development cover?
Redis development is designing, building and running the in-memory data layer that sits beside your main database: caches, session stores, rate limiters, job queues, leaderboards and streams. Agnotic Technologies chooses the Redis data structure, persistence setting, eviction policy and hosting for each job, and builds the application code that uses it.
Redis is usually not the system of record. When it has to be, persistence and replication are designed for that from the start, not switched on later.
Wider backend architecture sits with our backend development services, and cloud landing zones with cloud consulting. This page is about the Redis layer itself.
Decision table
Which Redis structure, persistence and eviction fit each workload?
Our starting settings for each job. Load testing and your failure tolerance decide the final values.
| Workload | Redis structure | Persistence | Eviction policy | Failure point if it is wrong |
|---|---|---|---|---|
| Page or API cache | Strings or hashes with a TTL | None or RDB | allkeys-lru or allkeys-lfu | Cache stampede when popular keys expire together |
| Session store | Hashes with a TTL per session | AOF every second, plus replicas | volatile-lru, or noeviction with memory headroom | Users logged out after a restart or an eviction |
| Rate limiter | Counters with INCR and EXPIRE, or sorted sets for sliding windows | None | noeviction | Limits reset or skipped when keys are evicted |
| Job queue | Streams with consumer groups | AOF every second | noeviction | Jobs lost on restart, or processed twice without acknowledgement |
| Leaderboard | Sorted sets | RDB or AOF, rebuildable from the database | noeviction | Scores lost with no source to rebuild them from |
| Pub/sub fan-out | Pub/sub channels | None; messages are not stored | Any | Disconnected subscribers miss messages; use streams when delivery matters |
| Event stream | Streams with trimming | AOF | noeviction | Memory grows until writes fail if streams are never trimmed |
Persistence and eviction are set per instance, so when one Redis serves jobs with different needs, we split them into separate instances.
Limits
What should Redis not hold?
Things we move out of Redis when we find them there.
- The only copy of business records, unless persistence and replication are designed for it
- Large blobs such as files and images, which belong in object storage
- Data you need to query ad hoc by many fields, which belongs in a database
- Unbounded lists or streams with no trimming
- Personal or health data in key names, which show up in logs and monitoring
- Anything you cannot rebuild if the cache is flushed
Failure points
Which Redis failures do we design against?
The incidents we see most in Redis layers, and the control for each.
Challenge
One hot key overloads a single shard.
Agnotic approach
Hot keys are split, or cached briefly inside the application.
Challenge
A KEYS command or a huge value blocks the server.
Agnotic approach
SCAN replaces KEYS, value sizes are capped and the slow log is watched.
Challenge
Memory fills and writes start failing.
Agnotic approach
maxmemory and the eviction policy are set for each instance, with alerts on memory use and fragmentation.
Challenge
A failover drops recent writes.
Agnotic approach
Data that must survive uses AOF and replicas, and the application treats what it cannot lose as a design decision, not a default.
Challenge
An open port exposes the instance.
Agnotic approach
Redis runs on private networks only, with TLS, an ACL user per application and dangerous commands disabled.
Hosting and licensing
Which Redis hosting option fits your team?
The choice depends on who runs it, which licence terms you accept and which features you need.
Managed service from your cloud
- Amazon ElastiCache, Google Cloud Memorystore or Azure's managed Redis service
- Patching, failover and backups handled by the provider
- Check the provider's compliance program and agreements before storing regulated data
Self-managed Redis Open Source
- Full control of version and configuration
- From Redis 8, a choice of RSALv2, SSPLv1 or AGPLv3 licence terms
- Your team runs replication, Sentinel or Cluster, and upgrades
Self-managed Valkey
- BSD-licensed project backed by the Linux Foundation
- Works with existing Redis clients for the features the two share
- Run by your team, or offered as a managed service by some cloud providers
High availability options
- Replicas for read scaling and failover
- Sentinel for automatic failover of a single primary
- Redis Cluster to shard data across several primaries
- Multi-zone placement on managed services
Who it is for
Who do we build Redis layers for?
Teams that need speed without losing data they care about.
High-traffic APIs and websites
Caching and rate limiting that keep the main database out of the hot path.
Multi-tenant SaaS products
Per-tenant rate limits, sessions and quotas shared across application instances.
Marketplaces and gaming
Leaderboards, counters and live feeds on sorted sets and streams.
Teams with an unmanaged Redis
A Redis that grew without settings, monitoring or a failover plan.
Fintech and healthcare apps
Sensitive workloads that need encryption, access control and careful key design.
What do we build and monitor in a Redis layer?
The Redis services we deliver, from the first cache to a clustered production setup.
Caching layer
Cache-aside or write-through caching with TTLs, jitter and stampede protection, wired into your API.
Sessions and rate limits
Session storage and sliding-window rate limiting shared across every application instance.
Queues and streams
Job queues on streams with consumer groups, acknowledgements, retries and dead-letter handling.
Security setup
ACL users per service, TLS in transit, encryption at rest on managed services and no personal data in key names.
High availability
Replicas, Sentinel or Cluster sized to your failure tolerance, proven with planned failovers.
Monitoring
Hit ratio, memory and fragmentation, evictions, slow log, latency and replication lag on one dashboard.
Technologies
Which Redis technologies do we work with?
Open source and managed options behind the hosting choices above.
Redis Open SourceValkeyAmazon ElastiCacheRedis SentinelRedis ClusterRedis Streams
Facts and sources
Facts behind Redis design choices
Redis and Valkey documentation, each linked to its primary source.
Redis offers RDB persistence, which takes point-in-time snapshots at set intervals, and AOF persistence, which logs every write; with the AOF fsync policy set to every second, the documentation notes you may lose one second of data in a disaster.
Source: Redis documentation: persistenceWhen Redis reaches its maxmemory limit, the noeviction policy returns errors for commands that store new data, while allkeys-lru and volatile-lru evict the least recently used keys from all keys or only from keys that have an expiry.
Source: Redis documentation: key evictionRedis access control lists limit each connection to specific commands and keys, after the client authenticates with a username and a valid password.
Source: Redis documentation: ACLStarting with Redis 8, Redis Open Source is available under a choice of three licences: the Redis Source Available License v2, the Server Side Public License v1 and the GNU Affero General Public License v3.
Source: Redis licensesValkey is an open source, BSD-licensed key/value datastore backed by the Linux Foundation, and it includes 3-Clause BSD-licensed Redis code.
Source: Valkey project site
Scope and cost
What drives the cost of Redis development?
Redis work is priced per engagement, not from a list. These factors set the size.
Number of workloads
How many jobs Redis will do: caching, sessions, rate limits, queues or streams.
Data you cannot lose
Whether any workload needs persistence, replicas and tested failover.
Traffic and key distribution
Request volume, hot keys and value sizes, which decide the topology.
Hosting choice
A managed service, self-managed Redis Open Source or Valkey.
Migration
Moving from Memcached, an in-process cache or an older Redis setup.
Compliance needs
Encryption, access control and agreements needed for regulated data.
Frequently Asked Questions
We do not publish prices. Cost depends on how many workloads Redis serves, what data must survive a failure, traffic and key distribution, the hosting choice and any migration. You receive a written proposal per workload after the scoping call.
Both handle most caching and queue workloads. The choice usually comes down to licence terms, what your cloud offers as a managed service and any feature only one of them has. We compare them against your requirements, without a default.
It can for some data, with AOF persistence, replicas, backups and a data model built around key access. For records you query in many ways or keep for years, a relational or document database is the safer home, with Redis in front.
Yes, with care: a managed service covered by the right agreement with your provider, encryption in transit and at rest, ACLs per service, short TTLs and no identifiers in key names. Our PHI data security work covers the wider controls.
Yes. We map each use of the old cache to a Redis structure, run both behind the application's cache interface, then switch over once hit ratios match.
Redis for startups is usually one managed instance doing caching and sessions. We set its eviction and persistence correctly from the start, so it can grow into queues and rate limits without surprises.