Redis Cache and Queue Workloads on Dockup

Redis cache and queue workloads may use the same managed Redis service, but they have different correctness requirements. A cache can usually be rebuilt after loss. A queue may represent work that must not be silently discarded or processed twice.

Dockup provisions Redis as a managed database, provides size and log operations, supports backup and node migration workflows, and can connect the database to application services through project-private networking.

How do you provision managed Redis?

Create Redis in the selected workspace:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Confirm the database target:

dockup db list --json

Store the returned connection material outside source control and attach it to the consuming service as a secret:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

The redeploy creates a new application container with the updated environment. A restart of the old container does not apply a newly stored desired value.

Use separate Redis databases or instances when cache eviction behavior and critical queue retention should not compete for the same memory. Isolation also simplifies incident diagnosis and access control.

When should Redis be used as a cache?

A cache reduces repeated work or latency by storing derived data. The source of truth remains elsewhere, usually PostgreSQL, MySQL, MongoDB, an external API, or deterministic computation.

A sound cache design defines:

• Cache key format and namespace.
• Time to live.
• Maximum acceptable staleness.
• Invalidation trigger.
• Behavior on a miss.
• Behavior when Redis is unavailable.
• Protection against a thundering herd.
• Which data must never be cached.

Failure	Safe cache behavior
Key missing	Recompute or read source of truth
Redis unavailable	Degrade to source with rate protection
Stale entry	Expire or invalidate
Serialization change	Version key namespace
Memory pressure	Evict rebuildable data first
Hot key	Add local cache, sharding, or request coalescing

Do not make the entire application unavailable solely because an optional cache is down. Use bounded timeouts and fallback paths. On the other hand, do not hide all failures; a sustained cache outage can overload the source database.

What changes when Redis is used as a job queue?

A queue represents pending work, so the application must define delivery and recovery semantics. Redis itself is a data structure server; guarantees depend on the queue library and worker protocol.

Decide:

1. When is a job considered accepted?
2. When is it acknowledged?
3. What happens if a worker crashes after performing the side effect but before acknowledgment?
4. How are retries delayed and capped?
5. Where do permanently failed jobs go?
6. How is duplicate execution made safe?
7. How is queue depth observed?
8. Can the job payload be reconstructed?

Build idempotent workers. A payment capture, email, or data import may be delivered more than once after a failure. Use a business idempotency key and record completion in the source-of-truth database.

Separate queue names by workload and priority. A slow media job should not starve password-reset or webhook processing. Avoid placing secrets in job payloads when a reference ID is sufficient.

A Redis cache and queue deployment should document which keys are disposable and which represent business work.

How does private networking connect services to Redis?

Enable project networking:

dockup network enable production --json

The Redis service becomes reachable by its stable <slug>.internal hostname from services in the same project. Redeploy the application so Dockup can inject the internal connection variables.

To make Redis private-only:

dockup db private production/app-redis --json

Restore the public listener when required:

dockup db private production/app-redis --off --json

Private networking removes the public internet path for same-project traffic but does not replace authentication. Keep the Redis connection material secret and restrict which services receive it.

Different projects cannot reach each other’s private network. This boundary can be useful when production and staging must not share cache keys or queue work.

See private networking and internal domains for the full model.

How should Redis failures affect the application?

Classify the workload before writing recovery code.

Workload	Loss tolerance	Outage response
HTML fragment cache	High	Rebuild from source
Session store	Low to medium	May log users out; design fallback
Rate-limit counters	Policy-dependent	Fail open or closed explicitly
Job queue	Low	Stop accepting or persist elsewhere
Distributed lock	Very low for critical sections	Use fencing/idempotency
Feature cache	High	Use default or source

A cache client should not retry forever. Long retries can consume every application worker and turn a Redis incident into a full outage. Queue workers should back off, expose failed work, and stop after a defined policy.

Inspect Redis size and the consuming application's runtime logs:

dockup db size production/app-redis --json
dockup logs production/api --json

Size growth can signal missing expiration, runaway queue depth, oversized payloads, or abandoned namespaces. Do not treat a database restart as the first response to application timeouts; check configuration, networking, and client behavior first.

How do backup, migration, and monitoring fit Redis?

Dockup exposes the managed database backup workflow:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

Whether a Redis backup meets the workload’s recovery goal depends on what the data means. A cache backup may be unnecessary. A queue backup may still lose work accepted after the backup point. Business-critical jobs should have a recoverable source record outside the queue when possible.

Move Redis between nodes with:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Plan migration impact on clients and workers. Confirm that reconnection, retry, and idempotency behavior work before production.

Monitor application-level metrics in addition to database size:

• Cache hit ratio.
• Miss latency.
• Evictions.
• Queue depth and oldest-job age.
• Job success, retry, and failure counts.
• Worker concurrency.
• Redis connection errors.
• Payload size.

Dockup measures CPU, RAM, and disk consumption per minute against the plan balance. The recommended Go plan costs $20 per month and includes $20 usage credit, but workload metrics—not the plan name—should drive capacity decisions.

What is a safe Redis production checklist?

Before launch, verify:

1. Exact project/db target.
2. Cache and queue responsibilities are documented.
3. Connection URL is a masked secret.
4. Private networking policy is decided.
5. Every cache has TTL or explicit invalidation.
6. Queue workers are idempotent.
7. Retry and dead-letter behavior is defined by the queue system.
8. Size and queue-depth alerts exist.
9. Backup value and limitations are understood.
10. Restart and migration are approval-gated.

Cache and queue separation example

A small application can begin with one Redis database when the risk is low, but use clear key prefixes:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

As the workload grows, separate critical queue state from aggressively evicted cache state. This is an operational boundary, not merely a naming preference.

A successful Redis cache and queue design makes the application’s behavior predictable when Redis is fast, slow, empty, or unavailable.

For relational source-of-truth operations, see managed PostgreSQL. For broader capacity choices, see database scaling strategies. Use the Dockup CLI reference for current database commands.

Define key and payload evolution

Cache and queue data outlive a single application process. A new release may read keys written by the previous release during a blue-green cutover. Version key namespaces and job payloads so both versions can coexist.

For queues, include a payload version and keep workers able to process at least the versions that may still be waiting. A deployment rollback can restore old code while new-format jobs remain in Redis. Without compatibility, application rollback may increase failures.

Test resource pressure deliberately

In a non-production environment, test missing keys, slow Redis responses, connection resets, queue backlog, duplicate delivery, and a full or near-full memory condition. Observe whether the application fails open, fails closed, retries, or overloads another dependency.

A Redis cache and queue runbook should set limits on retry attempts and concurrency. Unlimited retry loops can consume all workers and make recovery harder than the original incident.

Keep a source-of-truth recovery path

For critical jobs, store enough state in the primary database to reconstruct work after Redis loss. A queue should accelerate processing, not become the only record that a customer action occurred.

Start with a verifiable deployment

Provision Redis in a non-production project, test cache fallback and duplicate job delivery, and make the failure policy explicit before routing critical work.

Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.

FAQ

Can Dockup create managed Redis?

Yes. Use the managed database create command with type redis, then connect the application using the returned connection material stored as a secret.

Should cache and queue data share one Redis instance?

They can for a small low-risk workload, but separation is safer when cache eviction and critical queue retention have different availability and memory requirements.

Does Redis guarantee that a queued job runs exactly once?

No general exact-once guarantee should be assumed. Delivery semantics depend on the queue library and worker design, so make side effects idempotent.

Can Redis use Dockup private networking?

Yes. Enable the project network, redeploy consuming services for internal variables, and optionally make the Redis database private-only.

Is a Redis backup enough for a critical job queue?

Not necessarily. It represents a point in time and may not include newer accepted work. Keep recoverable source records and define application-level job recovery.