What is Redis? Installation, Commands and Real-World Usage Patterns

Redis (REmote DIctionary Server) is an in-memory data structure server that shows up somewhere in nearly every modern backend stack — as a cache, session store, rate limiter, message broker, leaderboard, geo index, even a small primary database. According to redis.io, a single Redis 7.x node typically delivers latencies between 0.1 and 0.5 ms and pushes hundreds of thousands of commands per second. This guide explains why Redis became this ubiquitous, walks through every data type with real commands, and covers production concerns from installation to clustering — with executable code in Node.js, Python and Docker.

What Redis Is and What It Solves

Related guides: PostgreSQL optimization · Advanced Git commands · Deploying with Docker · Docker Compose guide · KEYDAL software development

Redis is a key-value data structure engine that keeps everything in RAM on a single node. Because data lives in memory, latency is far lower than disk-based stores like PostgreSQL or MySQL. The command processing loop is mostly single-threaded; that gives strong atomicity guarantees — no two commands execute concurrently. For I/O Redis 6+ can use multiple threads via io-threads. Default port is 6379 and the wire format is the RESP protocol.

Typical use cases: caching slow database queries, holding HTTP sessions across requests, enforcing rate limits like N requests/minute, real-time pub/sub for notifications and chat, leaderboards, geo proximity (drivers nearby), counting tens of millions of unique visitors in constant memory with HyperLogLog, and Kafka-style event streams via Redis Streams.

Redis vs Memcached

Memcached is also an in-memory cache, but quite limited compared to Redis. The differences directly drive production choice:

• Data types: Memcached holds strings only. Redis supports strings, hashes, lists, sets, sorted sets, streams, bitmaps, hyperloglogs and geo.
• Persistence: Memcached is 100% volatile — restart wipes everything. Redis writes to disk via RDB and AOF.
• Replication and HA: Memcached has no built-in replication. Redis offers master-replica, Sentinel (automatic failover) and Cluster (sharding).
• Pub/Sub and Streams: Missing in Memcached; Redis ships both.
• Atomic commands: Because Redis runs commands sequentially on a single thread, INCR, SADD, ZADD and friends are atomic out of the box. Lua scripts let you bundle multiple commands into one atomic unit.
• Memory efficiency: Memcached can be slightly leaner for plain strings; Redis's listpack and tinyintset optimizations win for larger lists and hashes.

Practical rule: if you only need a cache and losing data is fine, Memcached works. If you need a hybrid (cache + queue + leaderboard + session), Redis is the only sensible choice.

Installation: apt, Docker and Managed

There are three practical ways to run Redis in production: a package manager (Ubuntu/Debian), a Docker container, or a managed service (Upstash, Redis Cloud, AWS ElastiCache). For local dev, Docker is fastest.

# Ubuntu/Debian — native install via apt
sudo apt update
sudo apt install -y redis-server
sudo systemctl enable --now redis-server

# Health check
redis-cli ping
# PONG

# Version
redis-server --version
# Redis server v=7.2.4 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64

# Docker (development)
docker run -d --name redis -p 6379:6379 redis:7-alpine

# Production-style (persistent volume + custom config)
docker run -d --name redis \
  -p 6379:6379 \
  -v redis-data:/data \
  -v $(pwd)/redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7-alpine redis-server /usr/local/etc/redis/redis.conf

# Redis Stack (RedisJSON, RediSearch, TimeSeries, Bloom bundled)
docker run -d --name redis-stack \
  -p 6379:6379 -p 8001:8001 \
  redis/redis-stack:latest

For managed Redis, Upstash is serverless and request-priced — small projects start at $0/month. AWS ElastiCache follows the classic always-on node model. Redis Inc. itself runs Redis Stack modules pre-loaded on Redis Cloud — see redis.io/docs/stack.

First Commands with redis-cli

redis-cli is the official terminal client. Once connected you can type commands interactively. The full command reference lives at redis.io/commands.

# Connect to local server
redis-cli

# Connect to a remote server with auth
redis-cli -h 10.0.0.5 -p 6379 -a 'StrongP@ss!' --no-auth-warning

# Run a single command and exit
redis-cli SET hello 'world'
redis-cli GET hello
# "world"

# Iterate keys (use SCAN, never KEYS, in production)
redis-cli --scan --pattern 'user:*' | head -20

# Latency probe
redis-cli --latency -i 1
# min: 0, max: 1, avg: 0.16 (1234 samples)

Data Type: String

The most basic and most used type. A binary-safe string lives at a key. Use INCR/DECR for counters and EXPIRE for TTL.

# Set/Get
SET user:1:name 'Egemen'
GET user:1:name
# "Egemen"

# With TTL (auto-deletes after 5 minutes)
SET session:abc123 '{"uid":42}' EX 300
TTL session:abc123
# (integer) 297

# Atomic counter (page views)
INCR pageviews:home
INCR pageviews:home
GET pageviews:home
# "2"

# Set only if absent (the building block of distributed locks)
SET lock:order:42 'worker-1' NX EX 30
# OK
SET lock:order:42 'worker-2' NX EX 30
# (nil)  ← lock not acquired

Data Type: List

A double-ended linked list. LPUSH/RPUSH push, LPOP/RPOP pop. BLPOP turns the list into a basic blocking worker queue.

# Use as a job queue
LPUSH jobs '{"type":"send_email","to":"a@b.com"}'
LPUSH jobs '{"type":"resize_image","id":42}'
LLEN jobs
# (integer) 2

# Worker (block up to 5s for a job)
BRPOP jobs 5
# 1) "jobs"
# 2) "{\"type\":\"send_email\",\"to\":\"a@b.com\"}"

# Range
LRANGE jobs 0 -1

# Keep only the latest 100 entries (sliding window)
LPUSH logs:app 'request from 1.2.3.4'
LTRIM logs:app 0 99

Data Type: Hash

Field→value pairs under a single key. Ideal for grouping structured data such as user profiles or product metadata under one key — all fields of the same user end up on the same node.

# User profile
HSET user:42 name 'Ada' email 'ada@example.com' age 33
HGET user:42 email
# "ada@example.com"

HGETALL user:42
# 1) "name"
# 2) "Ada"
# 3) "email"
# 4) "ada@example.com"
# 5) "age"
# 6) "33"

# Counter field (atomic increment)
HINCRBY user:42 login_count 1

# Subset of fields
HMGET user:42 name age

Data Type: Set

An unordered collection of unique strings. Useful for tags, follower lists and daily unique visitors. Set operations — intersection, union, difference — run server-side; from the application they feel like O(1).

# Tags on a post
SADD post:101:tags 'redis' 'cache' 'performance'
SMEMBERS post:101:tags

# Following / followers
SADD user:1:following 2 3 4
SADD user:2:following 1 4 5

# Mutually followed accounts (intersection)
SINTER user:1:following user:2:following
# 1) "4"

# Exact daily unique visitors (not approximate)
SADD visitors:2026-04-25 'ip:1.2.3.4' 'ip:5.6.7.8'
SCARD visitors:2026-04-25

Data Type: Sorted Set (ZSET)

An ordered set where each member has a score. The gold standard for leaderboards, latest/most-popular feeds and time-series-like ranking. Insert and ordered listing are O(log N).

# Game leaderboard
ZADD leaderboard 1500 'alice' 1820 'bob' 1340 'carol' 2100 'dave'

# Top 3 with scores
ZREVRANGE leaderboard 0 2 WITHSCORES
# 1) "dave"
# 2) "2100"
# 3) "bob"
# 4) "1820"
# 5) "alice"
# 6) "1500"

# Update score atomically
ZINCRBY leaderboard 50 'alice'

# Players in score range 1500-1900
ZRANGEBYSCORE leaderboard 1500 1900

# A player's rank
ZREVRANK leaderboard 'alice'

Bitmap, HyperLogLog and Geo

A bitmap is really a string with bit-level read/write. To track daily-active users (DAU), marking a user's activity for each day of the year takes 365 bits = 46 bytes — trivially cheap even for millions of users.

# DAU: user 42 logged in today
SETBIT dau:2026-04-25 42 1
GETBIT dau:2026-04-25 42
# (integer) 1

# Today's active count
BITCOUNT dau:2026-04-25
# (integer) 17834

# HyperLogLog — millions of uniques in ~12 KB
PFADD visitors:home 'ip:1.2.3.4' 'ip:5.6.7.8'
PFCOUNT visitors:home
# (integer) 2 (~±0.81% error)

# Geo — find nearby points
GEOADD drivers 28.9784 41.0082 'driver:1' 28.9850 41.0105 'driver:2'
GEOSEARCH drivers FROMLONLAT 28.98 41.01 BYRADIUS 2 km ASC
# 1) "driver:1"
# 2) "driver:2"

Data Type: Stream (Redis Streams)

An append-only log introduced in Redis 5+. As documented at redis.io/docs/data-types/streams, it provides Kafka-style consumer groups and per-message acknowledgment (XACK). It's the fastest way to publish events between microservices without standing up Kafka.

# Publish events
XADD events:orders * type 'created' order_id 1001 amount 250
XADD events:orders * type 'paid'    order_id 1001

# Stream length
XLEN events:orders
# (integer) 2

# Create a consumer group
XGROUP CREATE events:orders billing $ MKSTREAM

# Read as a worker (only new messages)
XREADGROUP GROUP billing worker-1 COUNT 10 BLOCK 5000 STREAMS events:orders >

# Acknowledge after processing
XACK events:orders billing 1714050000000-0

# Pending (delivered but not yet acked)
XPENDING events:orders billing

Cache Pattern: Cache-Aside (Lazy Loading)

The most common pattern. The app checks the cache first; on miss it reads the DB, writes back to cache and returns. A Node.js example with ioredis:

// npm i ioredis
import Redis from 'ioredis';
const redis = new Redis({ host: '127.0.0.1', port: 6379 });

async function getProduct(id) {
  const key = `product:${id}`;

  // 1) Cache
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  // 2) Database
  const product = await db.query('SELECT * FROM products WHERE id=$1', [id]);
  if (!product) return null;

  // 3) Backfill cache (10 min TTL)
  await redis.set(key, JSON.stringify(product), 'EX', 600);
  return product;
}

// Invalidate on update
async function updateProduct(id, patch) {
  await db.update(id, patch);
  await redis.del(`product:${id}`);
}

The same pattern in Python with redis-py:

# pip install redis
import json, redis
r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)

def get_product(pid: int):
    key = f'product:{pid}'
    cached = r.get(key)
    if cached:
        return json.loads(cached)

    product = db.fetch_one('SELECT * FROM products WHERE id=%s', (pid,))
    if not product:
        return None

    r.set(key, json.dumps(product), ex=600)
    return product

Cache Pattern: Write-Through and Write-Behind

Beyond cache-aside, two more patterns serve more demanding needs:

• Write-through: The app writes synchronously to both DB and cache. Lower stale-data risk, higher write latency.
• Write-behind (write-back): The app writes to the cache first; the cache flushes to DB asynchronously. Big wins for write-heavy systems but a crash window can lose data.
• Read-through: The app only talks to the cache; on miss, the cache itself fetches from the DB and fills. In Redis this typically lives in a library or a wrapper you write.

Session Store: Express, Django, Laravel

Storing HTTP sessions in Redis is a precondition for horizontal scaling — any app server can read the same session by its cookie ID. The official Express integration is connect-redis:

// npm i express express-session connect-redis ioredis
import express from 'express';
import session from 'express-session';
import { RedisStore } from 'connect-redis';
import Redis from 'ioredis';

const app = express();
const redis = new Redis(process.env.REDIS_URL);

app.use(session({
  store: new RedisStore({ client: redis, prefix: 'sess:' }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    maxAge: 1000 * 60 * 60 * 24 * 7  // 7 days
  }
}));

app.get('/', (req, res) => {
  req.session.views = (req.session.views || 0) + 1;
  res.send(`Views: ${req.session.views}`);
});

On Django, django-redis with SESSION_ENGINE = 'django.contrib.sessions.backends.cache'; on Laravel, SESSION_DRIVER=redis in .env and the Redis settings in config/database.php. In all three, only the session ID lives in the cookie — durable state lives in Redis.

Rate Limiting: Sliding Window with Lua

The simplest rate limit: INCR + EXPIRE. For a per-IP rule of 100 requests every 60 seconds, the key resets each minute. Fixed window, approximate but cheap:

// Naive fixed window — 100 req / 60 s
async function allow(ip) {
  const key = `rl:${ip}:${Math.floor(Date.now() / 60000)}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, 60);
  return count <= 100;
}

For a precise sliding window, run a Lua script atomically — no race conditions:

-- KEYS[1] = rate limit key (sorted set)
-- ARGV[1] = window length (s), ARGV[2] = limit, ARGV[3] = now (ms)
local window = tonumber(ARGV[1]) * 1000
local limit  = tonumber(ARGV[2])
local now    = tonumber(ARGV[3])
local cutoff = now - window

-- Drop old hits
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, cutoff)

-- Current count
local count = redis.call('ZCARD', KEYS[1])
if count >= limit then
  return 0  -- reject
end

-- Record this hit
redis.call('ZADD', KEYS[1], now, now)
redis.call('PEXPIRE', KEYS[1], window)
return 1  -- allow

// Use the script with ioredis
const script = fs.readFileSync('rate_limit.lua', 'utf8');
redis.defineCommand('ratelimit', { numberOfKeys: 1, lua: script });

async function allow(ip) {
  const ok = await redis.ratelimit(`rl:${ip}`, 60, 100, Date.now());
  return ok === 1;
}

Pub/Sub: Real-Time Notifications

PUBLISH/SUBSCRIBE deliver fire-and-forget messages to subscribers — perfect for browser push over WebSocket and instant inter-service events. Messages are not persisted; if no subscriber is listening, the message vanishes. For durability use Redis Streams instead.

// Publisher
import Redis from 'ioredis';
const pub = new Redis();
await pub.publish('notifications:user:42', JSON.stringify({
  type: 'message',
  from: 'alice',
  body: 'Hi!'
}));

// Subscriber — use a separate connection
const sub = new Redis();
await sub.subscribe('notifications:user:42');
sub.on('message', (channel, payload) => {
  const msg = JSON.parse(payload);
  console.log('New notification:', msg);
});

// Pattern subscribe
await sub.psubscribe('notifications:*');
sub.on('pmessage', (pattern, channel, payload) => { /* ... */ });

Redis 7 added sharded pub/sub via SSUBSCRIBE/SPUBLISH — in cluster mode, messages are delivered only on a single shard, drastically reducing the load broadcast across all nodes.

Persistence: RDB, AOF and Hybrid

Despite being in-memory, Redis can persist to disk. Two methods exist and are usually combined:

• RDB (snapshot): Periodically write the entire dataset to a single dump.rdb file. Fastest restart. Crash between snapshots loses everything written since the last snapshot.
• AOF (Append Only File): Every write command is appended to appendonly.aof. Crash loses at most as much as your fsync policy allows. The file grows; periodic BGREWRITEAOF compacts it.
• Hybrid (RDB + AOF): Since Redis 4, aof-use-rdb-preamble yes prefixes the AOF with an RDB snapshot. Restart is both fast and safe. This is the production default.

# /etc/redis/redis.conf — persistence
# RDB snapshots
save 900 1       # snapshot if >=1 change in 15 min
save 300 10
save 60  10000

# AOF
appendonly yes
appendfsync everysec     # fsync every second (best balance)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Hybrid format (Redis 4+)
aof-use-rdb-preamble yes

Replication and Sentinel

Master-replica replication: one master takes writes; replicas can be used to scale reads. On the replica, a single line — replicaof <master_ip> 6379 — is enough.

For high availability use Redis Sentinel. Sentinel monitors the master; when it goes down, Sentinel promotes a replica and steers clients there. Quorum-based, so 3 Sentinel nodes is the minimum recommendation.

# sentinel.conf — baseline
port 26379
sentinel monitor mymaster 10.0.0.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster 'StrongP@ss!'

Cluster: Sharding and Hash Slots

When a single master hits its RAM or CPU limits, Redis Cluster kicks in. Data is split across 16384 hash slots distributed over master nodes. Each master can have an optional replica. Modern client libraries (ioredis, redis-py, Lettuce) discover which key lives on which node automatically.

# Classic 6-node cluster (3 master + 3 replica)
redis-cli --cluster create \
  10.0.0.10:7000 10.0.0.11:7000 10.0.0.12:7000 \
  10.0.0.10:7001 10.0.0.11:7001 10.0.0.12:7001 \
  --cluster-replicas 1

# Send a command to the cluster
redis-cli -c -h 10.0.0.10 -p 7000
10.0.0.10:7000> SET user:1 'Ada'
-> Redirected to slot [5798] located at 10.0.0.11:7000
OK

# Add a new master and reshard
redis-cli --cluster add-node 10.0.0.13:7000 10.0.0.10:7000
redis-cli --cluster reshard 10.0.0.10:7000

In cluster mode, multi-key commands (MGET, MSET, MULTI/EXEC) only work when all keys hash to the same slot. Force them onto the same slot with a {tag} in the key: user:{42}:profile and user:{42}:sessions both land on the same node.

Memory Management and Eviction

The biggest production mistake with Redis is running it without maxmemory set. When RAM fills up, the OS swaps and Redis stalls. Always set a limit and pick an eviction policy. The full list is documented at redis.io/docs/manual/eviction.

• noeviction — writes are refused when full (use only for primary-DB style usage where data loss is unacceptable)
• allkeys-lru — evict the least recently used; all keys are candidates (most common cache choice)
• volatile-lru — LRU but only over keys with TTL
• allkeys-lfu — least frequently used (LFU often beats LRU when there's a clear hot set)
• volatile-ttl — evict keys closest to expiring first
• allkeys-random / volatile-random — random (rarely the right answer)

# redis.conf
maxmemory 4gb
maxmemory-policy allkeys-lru

# In cluster mode each node has its own maxmemory; total = nodes * limit

Security: AUTH, ACL, TLS

As the official security guide states, a production Redis must never be exposed directly to the public internet. Layer at least three controls on top:

• protected-mode yes — default, only listens on localhost without further config
• requirepass for password authentication
• ACL (Redis 6+) with per-app users limited to specific commands and key prefixes
• TLS for encrypted connections (mandatory on most managed services)
• bind 127.0.0.1 10.0.0.5 — listen only on specific NICs
• rename-command FLUSHALL '' to disable destructive commands

# redis.conf — security baseline
bind 127.0.0.1 10.0.0.5
protected-mode yes
requirepass 'a-very-long-and-random-string-32+chars'

# Disable destructive commands
rename-command FLUSHALL ''
rename-command FLUSHDB  ''
rename-command DEBUG    ''
rename-command CONFIG   ''

# TLS
tls-port 6380
port 0
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file  /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes

# ACL — per-app users
ACL SETUSER app-web on >App!Pass1 ~app:* +@read +@write -@dangerous
ACL SETUSER app-worker on >Wrk!Pass2 ~jobs:* +@stream +@list -@dangerous
ACL SETUSER readonly on >Read!Pass3 ~* +@read -@write

# List all users
ACL LIST

# Inspect command groups
ACL CAT

Monitoring and Diagnostics

INFO is your first stop for server health. SLOWLOG captures slow commands. MONITOR prints every command in real time — for development only; it adds significant overhead in production.

# Health summary
redis-cli INFO server | head
# redis_version:7.2.4
# redis_mode:standalone
# os:Linux 6.8.0-31-generic x86_64
# tcp_port:6379
# uptime_in_seconds:1284923

redis-cli INFO memory | grep used_memory_human
# used_memory_human:1.43G

redis-cli INFO stats | grep -E 'instantaneous_ops|total_connections'
# total_connections_received:184231
# instantaneous_ops_per_sec:8421

# Slow log: capture commands above 10ms
redis-cli CONFIG SET slowlog-log-slower-than 10000
redis-cli SLOWLOG GET 10

# Real-time latency histogram
redis-cli --latency-history -i 5

To plug into the Prometheus ecosystem, redis_exporter is the de facto choice. A single Docker container exposes a /metrics endpoint and several Grafana dashboards exist out of the box.

# docker-compose.yml — redis + exporter
services:
  redis:
    image: redis:7-alpine
    command: redis-server --requirepass ${REDIS_PASS}
    ports: ['6379:6379']

  redis-exporter:
    image: oliver006/redis_exporter
    environment:
      REDIS_ADDR: 'redis://redis:6379'
      REDIS_PASSWORD: ${REDIS_PASS}
    ports: ['9121:9121']

Pipeline, Transaction and Lua

To send multiple commands in one round-trip you have three options:

• Pipeline: Commands are sent in order, the server replies in order, but other clients can interleave. Best for raw latency reduction.
• MULTI/EXEC (transaction): Commands are queued and run atomically at EXEC; nothing else interleaves. Individual commands can still fail; there is no rollback.
• Lua script (EVAL): Runs server-side as a single atomic unit; the most powerful option for conditional logic. Redis 7 also provides FUNCTION as a more durable alternative.

// Pipeline
const pipe = redis.pipeline();
pipe.set('a', 1);
pipe.incr('a');
pipe.get('a');
const results = await pipe.exec();
// [[null,'OK'],[null,2],[null,'2']]

// Transaction
const tx = redis.multi();
tx.zadd('lb', 100, 'alice');
tx.zadd('lb', 200, 'bob');
await tx.exec();

Common Pitfalls

• Never run KEYS * in production — it scans every key and locks Redis on big datasets. Use SCAN.
• FLUSHALL wipes the entire dataset in one line. Lock it down via ACL or rename-command.
• During BGSAVE, fork() can double RAM usage; on cloud VMs this is a frequent OOM-kill cause. Plan for it.
• Don't put session contents in the cookie and key into Redis from there — keep only the session ID in the cookie. Bigger cookies hurt every request.
• Pub/Sub is not durable. For at-least-once delivery use Streams + consumer groups.
• You cannot mix regular commands with SUBSCRIBE on the same connection; subscribers need their own.
• TTL-less cache keys leak RAM forever; always pass an EX argument when caching.
• Long Lua scripts block the server. lua-time-limit kills runaway scripts; keep heavy work in batches.
• In cluster mode, forgetting {hashtag} for multi-key commands is a frequent bug.
• MSET key1 val1 key2 val2 sets multiple keys in one command but is less flexible than a pipeline; understand the trade-off.

Notable Redis 7.x Features

• Functions: A persistent replacement for Lua scripts. They survive restarts and replicate to replicas.
• Sharded Pub/Sub: Cluster-mode messages travel only on the relevant shard, not to every node.
• ACL v2: Channel-based permissions and more flexible key-pattern definitions.
• Multi-part AOF: AOF is now split across multiple files; rewrites are far cheaper.
• Listpack by default: ziplist is fully removed; small lists/hashes/zsets use less memory.

Which Setup for Which Workload?

• Dev / small production: single node, RDB + AOF, requirepass. One VPS is enough.
• High availability: 1 master + 2 replicas + 3 Sentinels. Automatic failover; tolerates one node loss.
• High volume / large dataset: Redis Cluster (3+ masters). Sharding plus 1 replica per shard.
• Serverless or spiky load: Upstash or another managed service. Connection counts stay sane and idle costs vanish.
• Modules (RediSearch, RedisJSON): Redis Stack image or Redis Cloud. Full-text search, JSON document type, time-series.

References

• Official site — redis.io
• Documentation — redis.io/docs
• All commands — redis.io/commands
• Replication — redis.io/docs/management/replication
• Sentinel — redis.io/docs/management/sentinel
• Cluster — redis.io/docs/management/scaling
• Security — redis.io/docs/manual/security
• Eviction — redis.io/docs/manual/eviction
• Streams — redis.io/docs/data-types/streams
• ioredis — github.com/redis/ioredis
• redis-py — github.com/redis/redis-py
• node-redis — github.com/redis/node-redis
• Redis Stack — redis.io/docs/stack
• Upstash (serverless) — upstash.com
• AWS ElastiCache — aws.amazon.com/elasticache
• redis_exporter — github.com/oliver006/redis_exporter

Modern Software Development and DevOps Practices

Professional software development rests on three pillars: version control (Git + GitHub/GitLab pull request flow, mandatory code review), CI/CD pipeline (automated test + lint + build + deploy), and observability (Sentry/Datadog/Grafana for logs, metrics, traces). The test pyramid (unit > integration > e2e) ensures code quality, microservice architecture uses Docker containers with Kubernetes orchestration, and REST or GraphQL APIs follow OpenAPI/GraphQL Schema contracts. Across the SDLC (requirements → design → implementation → test → deploy → maintenance), Agile/Scrum sprints last 1-2 weeks while DevOps teams practice continuous delivery.

Related Articles and Services

• PostgreSQL Performance Optimization — the database that sits behind your Redis cache
• Software Development: Process & Methodologies
• Nginx Configuration Guide — reverse proxy + cache strategy
• KEYDAL Software Development
• KEYDAL API Development